[Bug libdw/30047] New: libdw unable to handle DW_TAG_unspecified_type

["raj.khem at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 30047
           Summary: libdw unable to handle DW_TAG_unspecified_type
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libdw
          Assignee: unassigned at sourceware dot org
          Reporter: raj.khem at gmail dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

GNU assembler starting with 2.40 release is generating DW_TAG_unspecified_type
for assembly files [1] this is fixed in gdb [2], however, it shows up as one of
test failures in elfutils 


% ./funcretval
() _start: ./funcretval: dwfl_module_return_value_location: cannot handle DWARF
type description

The reason is that glibc startup files e.g. (/usr/lib/Scrt1.o) is built from
assembly routines and when compiled with toolchain using binutils 2.40 gets
these DW_TAG_unspecified_type entries emitted into its debug segments which
inturn get into the testcases when they are built in elfutils testsuites

native.c
=========
#include <unistd.h>
int main () { while (1) pause (); return 0;}

gcc -g native.c

./funcretval

then results in this error and failure in elfutils testcases

/usr/lib/elfutils/ptest/tests/funcretval: dwfl_module_return_value_location:
cannot handle DWARF type description
FAIL: run-native-test.sh

I think libdw has to implement handling DW_TAG_unspecified_type, since it will
start showing up everywhere soon as 2.40 binutils trickle into downstream
distributions and they do mass-rebuilds.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29559
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=29558

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