Re: buildfarm's typedefs list has gone completely nutso

On 7/10/19 8:24 PM, Andres Freund wrote:
> 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.

OK, I don't have a problem with that. I think the sane way to go would
be to replace it with what the buildfarm is using, more or less.

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

I assume you mean -W rather than -w

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

That seems new. I didn't get this in my attempt to recreate the setup of
your animal. That was on debian/buster which has binutils 2.31.1-16

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

This looks like a bug in the version of objdump unless I'm reading it
wrong. Why would this be tagged as a typedef?

I would tentatively suggest that you revert to the previous version of
binutils if possible, and consider reporting a bug in the bleeding edge
of objdump.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services