svn commit: r339350 - head/contrib/elftoolchain/elfcopy

[Antoine Brodin]

On Mon, Oct 15, 2018 at 3:53 PM Ed Maste <emaste at freebsd.org> wrote:
> On Mon, 15 Oct 2018 at 07:13, Ed Maste <emaste at 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.

The attached patch for the gcc ports fixes the failures for me.

Antoine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-strip.diff
Type: text/x-patch
Size: 4159 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20181016/5799f238/attachment.bin>