Date: Mon, 15 Oct 2018 05:54:34 -0400 From: Ed Maste <emaste@freebsd.org> To: Antoine Brodin <antoine@freebsd.org>, gerald@freebsd.org Cc: FreeBSD Release Engineering Team <re@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy Message-ID: <CAPyFy2B-Oc8rVk_iBd8z6ecK_htEF41CCEZ_9=29zMGwap5aKg@mail.gmail.com> In-Reply-To: <CAPyFy2Cv2ydYWmBvWxoM9ACw2iCnq7xfsngEyOPF7XNK7P8ckA@mail.gmail.com> References: <201810132126.w9DLQ73C022496@repo.freebsd.org> <CAALwa8k5k7T2Xy6jSq0bbj%2Biq0T_FwctOZ-=ZLkCU6eS1%2BCoKg@mail.gmail.com> <CAPyFy2Cv2ydYWmBvWxoM9ACw2iCnq7xfsngEyOPF7XNK7P8ckA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Oct 2018 at 07:13, Ed Maste <emaste@freebsd.org> wrote:
>
> Hi Antoine, did you bisect to this rev or does it just look like the
> most probable candidate? Can you copy a pair of differing .o files
> (say, gcc/cc1plus-checksum.o) from the work dir to freefall?
Antoine provided a tarball of the work dir to me, and pointed out that
the *-checksum.o files are not interesting - they are warnings only
and are present prior to the identified change.
Comparing one of the other differing files, e.g.
stage{2,3}-gcc/expmed.o, demonstrates the problem. Gcc's build
machinery is reasonably obfuscated so I'm not sure of the exact set of
operations, but I can infer that the stage2/stage3 comparison is
running strip on the object files and then comparing the result. Gcc
is encountering this part of my strip/objcopy change:
> Stripping binaries with relocations
> referencing removed symbols was already broken, and after this change
> may still be broken in a different way.
Stripping symbols and relocations from an object file is not a
particularly useful operation, since the object then can't be linked
or otherwise used. But it seems Gcc's stage comparison relies on this.
I did try running "strip --strip-debug" on stage{2,3}-gcc/expmed.o (a
reasonable operation on object files) and that produced identical
output.
It may well be that a further change to ELF Tool Chain's strip is
warranted, but I suspect the most straightforward and reliable fix
here will be to just have gcc use GNU strip.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2B-Oc8rVk_iBd8z6ecK_htEF41CCEZ_9=29zMGwap5aKg>