Created attachment 11047 [details] test-case I've just built elftuils with GCC 8.1.0 and I see: $ LD_LIBRARY_PATH=./libdw/ ./src/readelf -a -w ./backends/libebl_x86_64.so [snip] DWARF section [32] '.debug_loc' at offset 0x2fbd9: CU [ 2d] base: +0x0000000000001e60 <x86_64_reloc_type_name> Segmentation fault (core dumped) Valgrind tells: DWARF section [32] '.debug_loc' at offset 0x2fbd9: CU [ 2d] base: +0x0000000000001e60 <x86_64_reloc_type_name> ==19867== Invalid read of size 8 ==19867== at 0x41EC14: next_listptr_offset (readelf.c:4939) ==19867== by 0x41EC14: print_debug_loc_section (readelf.c:9247) ==19867== by 0x4122D8: print_debug (readelf.c:11075) ==19867== by 0x415610: process_elf_file (readelf.c:980) ==19867== by 0x41631C: process_dwflmod (readelf.c:744) ==19867== by 0x4E62020: dwfl_getmodules (dwfl_getmodules.c:86) ==19867== by 0x40883B: process_file (readelf.c:852) ==19867== by 0x4044C3: main (readelf.c:338) ==19867== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==19867== ==19867== ==19867== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==19867== Access not within mapped region at address 0x0 ==19867== at 0x41EC14: next_listptr_offset (readelf.c:4939) ==19867== by 0x41EC14: print_debug_loc_section (readelf.c:9247) ==19867== by 0x4122D8: print_debug (readelf.c:11075) ==19867== by 0x415610: process_elf_file (readelf.c:980) ==19867== by 0x41631C: process_dwflmod (readelf.c:744) ==19867== by 0x4E62020: dwfl_getmodules (dwfl_getmodules.c:86) ==19867== by 0x40883B: process_file (readelf.c:852) ==19867== by 0x4044C3: main (readelf.c:338) ==19867== If you believe this happened as a result of a stack ==19867== overflow in your program's main thread (unlikely but ==19867== possible), you can try to increase the size of the ==19867== main thread stack using the --main-stacksize= flag. ==19867== The main thread stack size used in this run was 8388608.
Thanks, for some reason we used the wrong listptr for locview attributes. This fixes it: diff --git a/src/readelf.c b/src/readelf.c index 2ccbea5..6f2f637 100644 --- a/src/readelf.c +++ b/src/readelf.c @@ -9244,7 +9244,7 @@ print_debug_loc_section (Dwfl_Module *dwflmod, if (attr == DW_AT_GNU_locviews) { - Dwarf_Off next_off = next_listptr_offset (&known_loclistsptr, + Dwarf_Off next_off = next_listptr_offset (&known_locsptr, listptr_idx); const unsigned char *locp = readp; const unsigned char *locendp; While looking at this I also noticed that for this test file eu-readelf --debug-dump=ranges claims to find some unused garbage in .debug_ranges, which might indicate that we are either missing some attributes in the associated CU, or GCC really puts garbage in the .debug_ranges section (which would surprise me).
(In reply to Mark Wielaard from comment #1) > While looking at this I also noticed that for this test file eu-readelf > --debug-dump=ranges claims to find some unused garbage in .debug_ranges, > which might indicate that we are either missing some attributes in the > associated CU, or GCC really puts garbage in the .debug_ranges section > (which would surprise me). That is odd. It seems eu-readelf really is correct, there is unused garbage in the .debug_ranges sections, but not generated by GCC, but by GNU AS: DWARF section [28] '.debug_info' at offset 0xe3c0: [Offset] Compilation unit at offset 0: Version: 2, Abbreviation section offset: 0, Address size: 8, Offset size: 4 [ b] compile_unit abbrev: 1 stmt_list (data4) 0 ranges (data4) range list [ 0] name (strp) "../sysdeps/x86_64/crti.S" comp_dir (strp) "/home/abuild/rpmbuild/BUILD/glibc-2.27/csu" producer (strp) "GNU AS 2.30.0" language (data2) Mips_Assembler (32769) [...] Compilation unit at offset 81846: Version: 2, Abbreviation section offset: 6828, Address size: 8, Offset size: 4 [ 13fc1] compile_unit abbrev: 1 stmt_list (data4) 23645 ranges (data4) range list [ 21a0] name (strp) "../sysdeps/x86_64/crtn.S" comp_dir (strp) "/home/abuild/rpmbuild/BUILD/glibc-2.27/csu" producer (strp) "GNU AS 2.30.0" language (data2) Mips_Assembler (32769) DWARF section [33] '.debug_ranges' at offset 0x3e2b0: CU [ b] base: +000000000000000000 <ELFUTILS_0.170.90> [ 0] base address +000000000000000000 <ELFUTILS_0.170.90> [ 10] <UNUSED GARBAGE> ... 48 bytes ... [...] CU [ 13fc1] base: +000000000000000000 <ELFUTILS_0.170.90> [ 21a0] base address +000000000000000000 <ELFUTILS_0.170.90> [ 21b0] <UNUSED GARBAGE IN REST OF SECTION> All the other CU/ranges look fine. I assume that GNU AS is padding the section for some reason. Anyway, this doesn't look like an eu-readelf bug.
(In reply to Mark Wielaard from comment #1) > Thanks, for some reason we used the wrong listptr for locview attributes. > This fixes it: > > diff --git a/src/readelf.c b/src/readelf.c > index 2ccbea5..6f2f637 100644 > --- a/src/readelf.c > +++ b/src/readelf.c > @@ -9244,7 +9244,7 @@ print_debug_loc_section (Dwfl_Module *dwflmod, > > if (attr == DW_AT_GNU_locviews) > { > - Dwarf_Off next_off = next_listptr_offset (&known_loclistsptr, > + Dwarf_Off next_off = next_listptr_offset (&known_locsptr, > listptr_idx); > const unsigned char *locp = readp; > const unsigned char *locendp; > > While looking at this I also noticed that for this test file eu-readelf > --debug-dump=ranges claims to find some unused garbage in .debug_ranges, > which might indicate that we are either missing some attributes in the > associated CU, or GCC really puts garbage in the .debug_ranges section > (which would surprise me). I can confirm it works for me! Thanks.
commit 84acd2365d4775b93aed5e5970b34db05ea5d547 Author: Mark Wielaard <mark@klomp.org> Date: Wed May 30 11:54:31 2018 +0200 readelf: Use correct listptr when looking up next loc for locview attr. We were using loclistsptr instead of locsptr in print_debug_loc_section. https://sourceware.org/bugzilla/show_bug.cgi?id=23247 Signed-off-by: Mark Wielaard <mark@klomp.org>