aboutsummaryrefslogtreecommitdiff
path: root/gdb/python
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2025-04-15 09:08:52 -0600
committerTom Tromey <tromey@adacore.com>2025-05-06 09:01:54 -0600
commitba005d32b0f3d6a8f7a35b649ffe46304bd7d6fb (patch)
tree3a956750c89dcf43a6df7b02431ec5869a1ee7dc /gdb/python
parent0dac4dded2b023080236474d4aea442d764a5049 (diff)
downloadbinutils-ba005d32b0f3d6a8f7a35b649ffe46304bd7d6fb.zip
binutils-ba005d32b0f3d6a8f7a35b649ffe46304bd7d6fb.tar.gz
binutils-ba005d32b0f3d6a8f7a35b649ffe46304bd7d6fb.tar.bz2
Handle dynamic field properties
I found a situation where gdb could not properly decode an Ada type. In this first scenario, the discriminant of a type is a bit-field. PROP_ADDR_OFFSET does not handle this situation, because it only allows an offset -- not a bit-size. My original approach to this just added a bit size as well, but after some discussion with Eric Botcazou, we found another failing case: a tagged type can have a second discriminant that appears at a variable offset. So, this patch changes this code to accept a general 'struct field' instead of trying to replicate the field-finding machinery by itself. This is handled at property-evaluation time by simply using a 'field' and resolving its dynamic properties. Then the usual field-extraction function is called to get the value. Because the baton now just holds a field, I renamed PROP_ADDR_OFFSET to PROP_FIELD. The DWARF reader now defers filling in the property baton until the fields have been attached to the type. Finally, I noticed that if the discriminant field has a biased representation, then unpack_field_as_long would not handle this either. This bug is also fixed here, and the test case checks this. Regression tested on x86-64 Fedora 41.
Diffstat (limited to 'gdb/python')
0 files changed, 0 insertions, 0 deletions