Re: buildfarm's typedefs list has gone completely nutso

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>
...

readelf --debug-dump src/interfaces/libpq/libpq.a
...
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x29268): GNU C17 8.3.0 -march=skylake -mmmx -mno-3dnow -msse -msse2 -m
<10> DW_AT_language : 12 (ANSI C99)
<11> DW_AT_name : (indirect string, offset: 0x28ef3): /home/andres/src/postgresql/src/interfaces/libpq/fe-auth.c
<15> DW_AT_comp_dir : (indirect string, offset: 0xf800): /home/andres/build/postgres/dev-assert/vpath/src/interfaces/l
...
<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: 0x4f12f): unsigned int
<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: 0x57deb): long int
<1><4b>: Abbrev Number: 4 (DW_TAG_typedef)
<4c> DW_AT_name : (indirect string, offset: 0x26129): size_t
<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.

Greetings,

Andres Freund