diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2021-09-30 22:38:29 -0400 |
---|---|---|
committer | Simon Marchi <simon.marchi@efficios.com> | 2021-10-07 11:03:54 -0400 |
commit | cd3f655cc7a55437a05aa8e7b1fcc9051b5fe404 (patch) | |
tree | 6ac5ac49884488ff6e8856d8d1ae7964a47866fe /gdb/cp-valprint.c | |
parent | 8baf3d07567f886be683aa26e3fc92346b604a93 (diff) | |
download | binutils-gdb-cd3f655cc7a55437a05aa8e7b1fcc9051b5fe404.tar.gz |
gdb: add accessors for field (and call site) location
Add accessors for the various location values in struct field. This
lets us assert that when we get a location value of a certain kind (say,
bitpos), the field's location indeed contains a value of that kind.
Remove the SET_FIELD_* macros, instead use the new setters directly.
Update the FIELD_* macros used to access field locations to go through
the getters. They will be removed in a subsequent patch.
There are places where the FIELD_* macros are used on call_site_target
structures, because it contains members of the same name (loc_kind and
loc). For now, I have replicated the getters/setters in
call_site_target. But we could perhaps eventually factor them in a
"location" structure that can be used at both places.
Note that the field structure, being zero-initialized, defaults to a
bitpos location with value 0. While writing this patch, I tried to make
it default to an "unset" location, to catch places where we would miss
setting a field's location. However, I found that some places relied on
the default being "bitpos 0", so I left it as-is. This change could
always be done as follow-up work, making these places explicitly set the
"bitpos 0" location.
I found two issues to fix:
- I got some failures in the gdb.base/infcall-nested-structs-c++.exp
test. They were caused by two functions in amd64-tdep.c using
TYPE_FIELD_BITPOS before checking if the location is of the bitpos
kind, which they do indirectly through `field_is_static`. Simply
move getting the bitpos below the field_is_static call.
- I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in
make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS,
and later access them through FIELD_ENUMVAL. Fix that by using
set_loc_enumval to set the value.
Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8
Diffstat (limited to 'gdb/cp-valprint.c')
-rw-r--r-- | gdb/cp-valprint.c | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/gdb/cp-valprint.c b/gdb/cp-valprint.c index f6969a5ab9d..ef7276af074 100644 --- a/gdb/cp-valprint.c +++ b/gdb/cp-valprint.c @@ -735,13 +735,13 @@ test_print_fields (gdbarch *arch) if (gdbarch_byte_order (arch) == BFD_ENDIAN_LITTLE) { f = append_composite_type_field_raw (the_struct, "A", bool_type); - SET_FIELD_BITPOS (*f, 1); + f->set_loc_bitpos (1); FIELD_BITSIZE (*f) = 1; f = append_composite_type_field_raw (the_struct, "B", uint8_type); - SET_FIELD_BITPOS (*f, 3); + f->set_loc_bitpos (3); FIELD_BITSIZE (*f) = 3; f = append_composite_type_field_raw (the_struct, "C", bool_type); - SET_FIELD_BITPOS (*f, 7); + f->set_loc_bitpos (7); FIELD_BITSIZE (*f) = 1; } /* According to the logic commented in "make_gdb_type_struct ()" of @@ -750,13 +750,13 @@ test_print_fields (gdbarch *arch) else { f = append_composite_type_field_raw (the_struct, "A", bool_type); - SET_FIELD_BITPOS (*f, 30); + f->set_loc_bitpos (30); FIELD_BITSIZE (*f) = 1; f = append_composite_type_field_raw (the_struct, "B", uint8_type); - SET_FIELD_BITPOS (*f, 26); + f->set_loc_bitpos (26); FIELD_BITSIZE (*f) = 3; f = append_composite_type_field_raw (the_struct, "C", bool_type); - SET_FIELD_BITPOS (*f, 24); + f->set_loc_bitpos (24); FIELD_BITSIZE (*f) = 1; } |