diff options
author | Tom Tromey <tromey@adacore.com> | 2025-04-15 09:08:52 -0600 |
---|---|---|
committer | Tom Tromey <tromey@adacore.com> | 2025-05-06 09:01:54 -0600 |
commit | ba005d32b0f3d6a8f7a35b649ffe46304bd7d6fb (patch) | |
tree | 3a956750c89dcf43a6df7b02431ec5869a1ee7dc /gdb/python | |
parent | 0dac4dded2b023080236474d4aea442d764a5049 (diff) | |
download | binutils-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