With gcc-11 and -gdwarf-5, we run into: ... (gdb) PASS: gdb.ada/arrayptr.exp: scenario=all: ptype string_access print pa_ptr.all^M Unhandled dwarf expression opcode 0xff^M (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all ... What happens is that there's an upper bound: ... <2><1509>: Abbrev Number: 12 (DW_TAG_subrange_type) <150a> DW_AT_lower_bound : 0 <150b> DW_AT_upper_bound : 0x3fffffffffffffffff <151b> DW_AT_name : foo__packed_array <151f> DW_AT_type : <0x15cc> <1523> DW_AT_artificial : 1 ... with form DW_FORM_data16: ... 12 DW_TAG_subrange_type [no children] DW_AT_lower_bound DW_FORM_data1 DW_AT_upper_bound DW_FORM_data16 DW_AT_name DW_FORM_strp DW_AT_type DW_FORM_ref4 DW_AT_artificial DW_FORM_flag_present DW_AT value: 0 DW_FORM value: 0 ... and: ... /* Return non-zero if ATTR's value falls in the 'constant' class, or zero otherwise. When this function returns true, you can apply the constant_value method to it. ... DW_FORM_data16 is not considered as constant_value cannot handle that. */ bool form_is_constant () const; ... so instead we have: ... bool attribute::form_is_block () const { return (form == DW_FORM_block1 || form == DW_FORM_block2 || form == DW_FORM_block4 || form == DW_FORM_block || form == DW_FORM_exprloc || form == DW_FORM_data16); } ... so in attr_to_dynamic_prop we end up doing "prop->set_locexpr (baton)" and have a PROC_LOCEXPR instead of a PROP_CONST and end up trying to evaluate the constant 0x3fffffffffffffffff as if it were a locexpr.
With this: ... $ git diff diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 029b8bfad04..8b603e8acae 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -18247,6 +18247,9 @@ attr_to_dynamic_prop (const struct attribute *attr, struct die _info *die, if (attr == NULL || prop == NULL) return 0; + if (attr->form == DW_FORM_data16) + return 0; + if (attr->form_is_block ()) { baton = XOBNEW (obstack, struct dwarf2_property_baton); ... we have: ... (gdb) PASS: gdb.ada/arrayptr.exp: scenario=all: ptype string_access print pa_ptr.all^M $7 = (10, 20, 30, 40, 50, 60, 62, 63, -23, 42)^M (gdb) PASS: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all ... but also with set complaints 1000: ... During symbol reading: Unresolved DW_AT_upper_bound - DIE at 0x1528 [in module foo] ...
With scenario minimal, we have initially the same error: ... (gdb) PASS: gdb.ada/arrayptr.exp: scenario=minimal: ptype string_access print pa_ptr.all^M Unhandled dwarf expression opcode 0xff^M (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all ... but with the patch that turns into: ... (gdb) PASS: gdb.ada/arrayptr.exp: scenario=minimal: ptype string_access print pa_ptr.all^M $7 = 394983413522922703370^M (gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all ...
https://sourceware.org/pipermail/gdb-patches/2021-July/181114.html
For dynamic properties, this is probably a dup of the new 128-bit bug. The idea being to store the form data into the property, but have the property accessors return a gdb_mpz.