[Bug gdb/20426] New: gdb does not interpret DWARF annotating imported units fully

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

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

            Bug ID: 20426
           Summary: gdb does not interpret DWARF annotating imported units
                    fully
           Product: gdb
           Version: 7.11.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 9412
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9412&action=edit
partially linked executable

For

int main(int argc, char **argv)
{
  void *a[argc-1];
  for (int i = 1; i < argc; ++i)
    a[i-1] = argv[i];
  return 0;
}

when compiled with GCC LTO in a private branch produces the attached
debug info.  gdb is not able to pick up DW_AT_upper_bound for the VLA
type correctly.  GCC emits it like

 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x44): GNU C11 7.0.0
201
60801 (experimental) [trunk revision 221942] -mtune=generic -march=x86-64 -g
-fl
to
    <10>   DW_AT_language    : 12       (ANSI C99)
    <11>   DW_AT_name        : t.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0xa):
/abuild/rguenther
/obj-early-lto-debug-g/gcc
 <1><19>: Abbrev Number: 2 (DW_TAG_subprogram)
    <1a>   DW_AT_external    : 1
    <1a>   DW_AT_name        : (indirect string, offset: 0x3f): main
...
 <2><3e>: Abbrev Number: 4 (DW_TAG_variable)
    <3f>   DW_AT_type        : <0x72>
    <43>   DW_AT_artificial  : 1
...
 <2><43>: Abbrev Number: 5 (DW_TAG_variable)
    <44>   DW_AT_name        : a
    <46>   DW_AT_decl_file   : 1
    <47>   DW_AT_decl_line   : 3
    <48>   DW_AT_type        : <0x79>
...
 <1><79>: Abbrev Number: 10 (DW_TAG_array_type)
    <7a>   DW_AT_type        : <0x8c>
    <7e>   DW_AT_sibling     : <0x8c>
 <2><82>: Abbrev Number: 11 (DW_TAG_subrange_type)
    <83>   DW_AT_type        : <0x72>
    <87>   DW_AT_upper_bound : <0x3e>
 <2><8b>: Abbrev Number: 0
...
 <0><9a>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <9b>   DW_AT_producer    : 
    <9c>   DW_AT_language    : 12       (ANSI C99)
    <9d>   DW_AT_low_pc      : 0x0
    <a5>   DW_AT_high_pc     : 0xfd
    <ad>   DW_AT_stmt_list   : 0x0
 <1><b1>: Abbrev Number: 2 (DW_TAG_imported_unit)
    <b2>   DW_AT_import      : <0xb>    [Abbrev Number: 1]
 <1><b6>: Abbrev Number: 3 (DW_TAG_subprogram)
    <b7>   DW_AT_abstract_origin: <0x19>
    <bb>   DW_AT_low_pc      : 0x0
    <c3>   DW_AT_high_pc     : 0xfd
    <cb>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_cfa)
    <cd>   DW_AT_GNU_all_call_sites: 1
...
 <2><df>: Abbrev Number: 5 (DW_TAG_variable)
    <e0>   DW_AT_abstract_origin: <0x3e>
    <e4>   DW_AT_location    : 2 byte block: 91 60      (DW_OP_fbreg: -32)
 <2><e7>: Abbrev Number: 5 (DW_TAG_variable)
    <e8>   DW_AT_abstract_origin: <0x43>
    <ec>   DW_AT_location    : 4 byte block: 91 a0 7f 6         (DW_OP_fbreg:
-96; DW_OP_deref)
...

where nothing in the DWARF standard suggests that the above wouldn't complete
DW_AT_upper_bound properly (it doesn't matter whether abstract origin or
specification is used).  It would be a shame if the importing CU needs
to pull in the array type its subrange type just to adjust its upper bound.

Note that it doesn't seem to matter (for gdb) whether the importing CU
refers to the imported DIEs via DW_AT_abstract_origin or DW_AT_specification.

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