[Bug symtab/28127] New: DW_FORM_data16 support

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28127

            Bug ID: 28127
           Summary: DW_FORM_data16 support
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.