Re: buildfarm's typedefs list has gone completely nutso - Mailing list pgsql-hackers

From Andres Freund
Subject Re: buildfarm's typedefs list has gone completely nutso
Date
Msg-id 20190717023539.avdxldvt7cpw347l@alap3.anarazel.de
Whole thread Raw
In response to Re: buildfarm's typedefs list has gone completely nutso  (Andres Freund <andres@anarazel.de>)
Responses Re: buildfarm's typedefs list has gone completely nutso  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: pg_stat_replication lag fields return non-NULL values even with NULLLSNs
Next
From: "Matsumura, Ryo"
Date:
Subject: RE: Bug: ECPG: Cannot use CREATE AS EXECUTE statemnt