[Bug binutils/24818] New: objdump -W resolves indirect strings incorrectly (all as offset 0x0) since 39f0547e554d

[andres at anarazel dot de]

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

            Bug ID: 24818
           Summary: objdump -W resolves indirect strings incorrectly (all
                    as offset 0x0) since 39f0547e554d
           Product: binutils
           Version: 2.33 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: andres at anarazel dot de
                CC: nickc at redhat dot com
  Target Milestone: ---

Created attachment 11911
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11911&action=edit
trivial demo program

Hi,

objdump -W, after commit 

commit 39f0547e554df96608dd041d2a7b3c72882fd515
Author: Nick Clifton <address@hidden>
Date:   2019-02-25 12:15:41 +0000

    Extend objdump's --dwarf=follow-links option so that separate debug info
files will also be affected by other dump function, and symbol tables from
separate debug info files will be used when disassembling the main file.

doesn't handle indirect strings correctly anymore, resolving them all to offset
0x0, which obviously isn't correct.

With the attached trivial test program, compiled with gcc-8 -ggdb -c
/tmp/test.c -o /tmp/test.o, I get:

$ objdump -W /tmp/test.o|head -n 20|tail -n -10
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x0): /home/andres
    <10>   DW_AT_language    : 12       (ANSI C99)
    <11>   DW_AT_name        : (indirect string, offset: 0x0): /home/andres
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x0): /home/andres
    <19>   DW_AT_low_pc      : 0x0
    <21>   DW_AT_high_pc     : 0x1e
    <29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_typedef)
    <2e>   DW_AT_name        : (indirect string, offset: 0x0): /home/andres

where all those references to /home/andres are just the first entry in
.debug_str (unsurprisingly, given the computed offset):

$ objdump -Ws /tmp/test.o

/tmp/test.o:     file format elf64-x86-64

Contents of the .debug_str section:

  0x00000000 2f686f6d 652f616e 64726573 00474e55 /home/andres.GNU
  0x00000010 20433137 20382e33 2e30202d 6d74756e  C17 8.3.0 -mtun
  0x00000020 653d6765 6e657269 63202d6d 61726368 e=generic -march
  0x00000030 3d783836 2d363420 2d676764 62002f74 =x86-64 -ggdb./t
  0x00000040 6d702f74 6573742e 63007265 74310072 mp/test.c.ret1.r
  0x00000050 65743200 646f7562 6c650066 6f6f6261 et2.double.fooba
  0x00000060 72310066 6f6f6261 723200            r1.foobar2.

If I use all the -W options *except* kK, I get correct output:

$ objdump -WlLiaprmfFsoRtUuTgAc /tmp/test.o|head -n 20|tail -n -10
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0xd): GNU C17 8.3.0
-mtune=generic -march=x86-64 -ggdb
    <10>   DW_AT_language    : 12       (ANSI C99)
    <11>   DW_AT_name        : (indirect string, offset: 0x3e): /tmp/test.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x0): /home/andres
    <19>   DW_AT_low_pc      : 0x0
    <21>   DW_AT_high_pc     : 0x1e
    <29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_typedef)
    <2e>   DW_AT_name        : (indirect string, offset: 0x5b): foobar1

Same if I revert to a commit before 39f0547e554df96608dd041d2a7b3c72882fd515,
even with all of -W specified. It seems pretty clear that computing offset 0x0
for every indirect string wasn't a intentional side-effect of that commit.

Regards,

Andres

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