Re: buildfarm's typedefs list has gone completely nutso

Hi,

On 2019-07-16 19:35:39 -0700, Andres Freund wrote:
> Hi,
>
> On 2019-07-10 17:24:41 -0700, Andres Freund wrote:
> > Not yet sure what's actually going on, but there's something odd with
> > debug information afaict:
> >
> > objdump -W spits out warnings for a few files, all static libraries:
> >
> > ../install/lib/libpgcommon.a
> > objdump: Warning: Location list starting at offset 0x0 is not terminated.
> > objdump: Warning: Hole and overlap detection requires adjacent view lists and loclists.
> > objdump: Warning: There are 3411 unused bytes at the end of section .debug_loc
>
> ...
>
>
> Interestingly, for the same files, readelf spits out correct
> data. E.g. here's a short excerpt from libpq.a:
>
> objdump -W src/interfaces/libpq/libpq.a
> ...
> <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <c> DW_AT_producer : (indirect string, offset: 0x0): SYNC_FILE_RANGE_WRITE 2
> <10> DW_AT_language : 12 (ANSI C99)
> <11> DW_AT_name : (indirect string, offset: 0x0): SYNC_FILE_RANGE_WRITE 2
> <15> DW_AT_comp_dir : (indirect string, offset: 0x0): SYNC_FILE_RANGE_WRITE 2
> ...
> <1><31>: Abbrev Number: 2 (DW_TAG_typedef)
> <32> DW_AT_name : Oid
> <36> DW_AT_decl_file : 30
> <37> DW_AT_decl_line : 31
> <38> DW_AT_decl_column : 22
> <39> DW_AT_type : <0x3d>
> <1><3d>: Abbrev Number: 3 (DW_TAG_base_type)
> <3e> DW_AT_byte_size : 4
> <3f> DW_AT_encoding : 7 (unsigned)
> <40> DW_AT_name : (indirect string, offset: 0x0): SYNC_FILE_RANGE_WRITE 2
> <1><44>: Abbrev Number: 3 (DW_TAG_base_type)
> <45> DW_AT_byte_size : 8
> <46> DW_AT_encoding : 5 (signed)
> <47> DW_AT_name : (indirect string, offset: 0x0): SYNC_FILE_RANGE_WRITE 2
> <1><4b>: Abbrev Number: 4 (DW_TAG_typedef)
> <4c> DW_AT_name : (indirect string, offset: 0x0): SYNC_FILE_RANGE_WRITE 2
> <50> DW_AT_decl_file : 2
> <51> DW_AT_decl_line : 216
> <52> DW_AT_decl_column : 23
> <53> DW_AT_type : <0x57>

> so it seems that objdump mis-parses all indirect strings - which IIRC is
> something like a pointer into a "global" string table, assuming the
> offset to be 0. That then just returns the first table entry.
>
> It doesn't happen with a slightly older version of binutils. Bisecting
> now.

It's

commit 39f0547e554df96608dd041d2a7b3c72882fd515 (HEAD, refs/bisect/bad)
Author: Nick Clifton <nickc(at)redhat(dot)com>
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.

* objdump.c (sym_ok): New function.
(find_symbol_for_address): Use new function.
(disassemble_section): Compare sections by name, not pointer.
(dump_dwarf): Move code to initialise byte_get pointer and iterate
over separate debug files from here to ...
(dump_bfd): ... here. Add parameter indicating that a separate
debug info file is being dumped. For main file, pull in the
symbol tables from all separate debug info files.
(display_object): Update call to dump_bfd.
* doc/binutils.texi: Document extened behaviour of the
--dwarf=follow-links option.
* NEWS: Mention this new feature.
* testsuite/binutils-all/objdump.WK2: Update expected output.
* testsuite/binutils-all/objdump.exp (test_follow_debuglink): Add
options and dump file parameters.
Add extra test.
* testsuite/binutils-all/objdump.WK3: New file.
* testsuite/binutils-all/readelf.exp: Change expected output for
readelf -wKis test.
* testsuite/binutils-all/readelf.wKis: New file.

luckily that allowed me to find a workaround too. If objdump -W's k and K
parameters (or --dwarf=links,=follow-links) aren't enabled, the dump
comes out correctly:

objdump -WlLiaprmfFsoRtUuTgAckK /tmp/test.o|grep -A5 '(DW_TAG_compile_unit)'
<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

objdump -WlLiaprmfFsoRtUuTgAc /tmp/test.o|grep -A5 '(DW_TAG_compile_unit)'
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x2a): GNU C17 9.1.0 -mtune=generic -march=x86-64 -ggdb -fasynchronous-
<10> DW_AT_language : 12 (ANSI C99)
<11> DW_AT_name : (indirect string, offset: 0x14): /tmp/test.c
<15> DW_AT_comp_dir : (indirect string, offset: 0x0): /home/andres
<19> DW_AT_low_pc : 0x0

(lLiaprmfFsoRtUuTgAckK just is all sub-parts of -W that my objdump knows
about)

looking at the .debug_str section (with -Ws):

0x00000000 2f686f6d 652f616e 64726573 00646f75 /home/andres.dou
0x00000010 626c6500 2f746d70 2f746573 742e6300 ble./tmp/test.c.
0x00000020 72657431 00726574 3200474e 55204331 ret1.ret2.GNU C1
0x00000030 3720392e 312e3020 2d6d7475 6e653d67 7 9.1.0 -mtune=g
0x00000040 656e6572 6963202d 6d617263 683d7838 eneric -march=x8
0x00000050 362d3634 202d6767 6462202d 66617379 6-64 -ggdb -fasy
0x00000060 6e636872 6f6e6f75 732d756e 77696e64 nchronous-unwind
0x00000070 2d746162 6c657300 666f6f62 61723100 -tables.foobar1.
0x00000080 666f6f62 61723200 foobar2.

it makes sense why in this case all strings are /home/andres, and also
why the precise symbols output into the typedef list appears to be
pretty random - it's just the first string, as the offsets are
mis-computed. And not all strings are put into the string table, which
explains why the output still has some contents left.

It turns out that -Wi is actually all we need - so I'll probably patch
my animals to use that for now, until the bug is fixed.

It might actually be sensible to always do that - it's a lot cheaper
that way:

$ time objdump -WlLiaprmfFsoRtUuTgAc src/interfaces/libpq/libpq.a|wc
747866 5190832 48917526

real 0m0.827s
user 0m1.040s
sys 0m0.074s

$ time objdump -Wi src/interfaces/libpq/libpq.a|wc
78703 378433 3594563

real 0m0.075s
user 0m0.076s
sys 0m0.025s

Greetings,

Andres Freund