[Bug default/19204] libabigail aborts on DWARF referencing non-existing DIE

["dodji at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #6 from dodji at redhat dot com ---
> Look at the DIE below:
>
>
>  [ 8a26a]        member
>                  name                 (string) "call_stack"
>                  accessibility        (data1) public (1)
>                  data_member_location (block1) 
>                   [   0] plus_uconst 24
>                  type                 (ref8) [ 84e09]
>
> Note how the "type" attribute refers to a DIE of offset '84e09'.
>
> The problem is that there is no DIE with offset 84e09 in the debug info file!

I wanted to add that the offending DIE at offset 0x8a26a (which
references the the non-existing DIE 0x84e09) comes from the translation
unit "../gperftools-2.4/src/memory_region_map.cc", built from directory
"/g/g0/legendre/tools/gperftools/bgq_xlc_build".

This info comes from look at the debug info for the compilation unit
which which contains DIE 8a26a:

---------------------------------->8<--------------------------------------
Compilation unit at offset 544265:
Version: 2, Abbreviation section offset: 13740, Address size: 8, Offset size: 8
[ 84e20]  compile_unit
          name                 (string)
"../gperftools-2.4/src/memory_region_map.cc"
          stmt_list            (data8) 84147
          low_pc               (addr) +0x00000000000c8260
          high_pc              (addr) +0x00000000000d0c24
          language             (data1) C_plus_plus (4)
          comp_dir             (string)
"/g/g0/legendre/tools/gperftools/bgq_xlc_build"
---------------------------------->8<--------------------------------------

So if we are to submit the issue to the compiler folks, we'd probably
need to provide them with the preprocessed output of the file
gperftools-2.4/src/memory_region_map.cc as well as the resulting *.o
binary, compiled with debug info generation turned on, and on which we'd
have made sure to see the DIE for the "LockHolder::call_stack" data
member which references a type DIE which is not present in the debug
info.  Or maybe it's present in the *.o file and it's the linker which
wrongly removes it later?

Anyway, food for thought (and investigation).

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