Re: buildfarm's typedefs list has gone completely nutso

Hi,

On 2019-07-10 16:40:20 -0400, Andrew Dunstan wrote:
> On 7/10/19 1:34 PM, Andres Freund wrote:
> >
> > Hm, it has gotten gcc-9 installed recently, but calliphoridae isn't
> > using that. So it's probably not the compiler side. But I also see a
> > binutils upgrade:
> >
> > 2019-07-08 06:22:48 upgrade binutils-multiarch:amd64 2.31.1-16 2.32.51.20190707-1
> >
> > and corresponding upgrades forall the arch specific packages. I suspect
> > it might be that.
> >
> > I can't immediately reproduce that locally though, using the same
> > version of binutils. It's somewhat annoying that the buildfarm uses a
> > different form of computing the typedefs than src/tools/find_typedef ...

> That script is notably non-portable, and hasn't seen any significant
> update in a decade.

I think that's kinda what I'm complaining about... It seems like a bad
idea to have this in the buildfarm code, rather than our code. IMO the
buildfarm code should invoke an updated src/tools/find_typedef - that
way people at least can create typedefs manually locally.

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

../install/lib/libecpg.a
objdump: Warning: Hole and overlap detection requires adjacent view lists and loclists.
objdump: Warning: There are 8450 unused bytes at the end of section .debug_loc

../install/lib/libpgcommon_shlib.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

../install/lib/libpgfeutils.a
objdump: Warning: Hole and overlap detection requires adjacent view lists and loclists.
objdump: Warning: There are 3090 unused bytes at the end of section .debug_loc

../install/lib/libpgport.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 38 unused bytes at the end of section .debug_loc

../install/lib/libpgtypes.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 13199 unused bytes at the end of section .debug_loc

../install/lib/libecpg_compat.a
objdump: Warning: Hole and overlap detection requires adjacent view lists and loclists.
objdump: Warning: There are 15001 unused bytes at the end of section .debug_loc

../install/lib/libpgport_shlib.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 38 unused bytes at the end of section .debug_loc

../install/lib/libpq.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 5528 unused bytes at the end of section .debug_loc

Not sure if that's related - I don't get that locally (newer compiler,
different compiler options, same binutils).

Interestingly pg_fprintf is only generated by pg_fprintf, as far as I
can tell, and the 1/2 typedefs are from libpq. The relevant entries look
like:

<1><4b>: Abbrev Number: 4 (DW_TAG_typedef)
<4c> DW_AT_name : (indirect string, offset: 0x0): USE_SSE42_CRC32C_WITH_RUNTIME_CHECK 1
<50> DW_AT_decl_file : 2
<51> DW_AT_decl_line : 216
<52> DW_AT_decl_column : 23
<53> DW_AT_type : <0x57>

So I suspect it might be the corruption/misparsing of objdump that's to
blame. Kinda looks like there's an issue with the dwarf stringtable, and
thus the wrong strings (debug information for macros in this case) is
being picked up.

Greetings,

Andres Freund