Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Fri, 19 Oct 2018 at 09:54, Gerald Pfeifer wrote: > > On Thu, 18 Oct 2018, Ed Maste wrote: > > I think this is probably the right approach, although I also have an > > ELF Tool Chain fix in D17596 which is waiting on the code freeze to > > end. > > I'm a little confused: This was broken most recently (as the mail > bomb that my inbox received from the pkg cluster and others indicates), > so at this point in the release cycle shouldn't > (a) the change causing all this be reverted, *or* Unfortunately there are subsequent changes that depend on the original fix which would also have to be unwound, it's not as easy as just reverting this one. > (b) a follow-up patch committed immediately, > whatever looks less risky? The follow-up patch is ready but is waiting on re@. At this point I expect I can commit in two days and then will need to re-request to merge to stable/12. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On 19.10.18 15:54, Gerald Pfeifer wrote: On Thu, 18 Oct 2018, Ed Maste wrote: I think this is probably the right approach, although I also have an ELF Tool Chain fix in D17596 which is waiting on the code freeze to end. I'm a little confused: This was broken most recently (as the mail bomb that my inbox received from the pkg cluster and others indicates), so at this point in the release cycle shouldn't (a) the change causing all this be reverted, *or* (b) a follow-up patch committed immediately, whatever looks less risky? Good to know, then I can stop investigating the bootstrap comparison failures. Thanks, Andreas ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Thu, 18 Oct 2018, Ed Maste wrote: > I think this is probably the right approach, although I also have an > ELF Tool Chain fix in D17596 which is waiting on the code freeze to > end. I'm a little confused: This was broken most recently (as the mail bomb that my inbox received from the pkg cluster and others indicates), so at this point in the release cycle shouldn't (a) the change causing all this be reverted, *or* (b) a follow-up patch committed immediately, whatever looks less risky? Gerald ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Tue, 16 Oct 2018 at 01:39, Antoine Brodin wrote: > > The attached patch for the gcc ports fixes the failures for me. I think this is probably the right approach, although I also have an ELF Tool Chain fix in D17596 which is waiting on the code freeze to end. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Tue, Oct 16, 2018 at 10:26:14AM +0300, Konstantin Belousov wrote:
> On Tue, Oct 16, 2018 at 07:39:32AM +0200, Antoine Brodin wrote:
> > On Mon, Oct 15, 2018 at 3:53 PM Ed Maste wrote:
> > > On Mon, 15 Oct 2018 at 07:13, Ed Maste 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
>
> > Index: lang/gcc48/Makefile
> > ===
> > --- lang/gcc48/Makefile (revision 482165)
> > +++ lang/gcc48/Makefile (working copy)
> > @@ -33,6 +33,7 @@
> > SUFFIX=${PORTVERSION:C/([0-9]+).([0-9]+).*/\1\2/}
> > USES= compiler cpe gmake iconv libtool makeinfo perl5
> > tar:bzip2
> > USE_BINUTILS= yes
> > +BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
> Shouldn't USE_BINUTILS automatically prefer all binaries from there to be
> used, instead of the base system variants ?
>
Strip is not in the list of binaries to override, probably something to fix.
Plus it expects the build system to respect the "classic" env var, which imho
should be replaced by BINARY_ALIAS when possible
Best regards,
Bapt
signature.asc
Description: PGP signature
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Tue, Oct 16, 2018 at 07:39:32AM +0200, Antoine Brodin wrote:
> On Mon, Oct 15, 2018 at 3:53 PM Ed Maste wrote:
> > On Mon, 15 Oct 2018 at 07:13, Ed Maste 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
> Index: lang/gcc48/Makefile
> ===
> --- lang/gcc48/Makefile (revision 482165)
> +++ lang/gcc48/Makefile (working copy)
> @@ -33,6 +33,7 @@
> SUFFIX= ${PORTVERSION:C/([0-9]+).([0-9]+).*/\1\2/}
> USES=compiler cpe gmake iconv libtool makeinfo perl5
> tar:bzip2
> USE_BINUTILS=yes
> +BINARY_ALIAS=strip=${LOCALBASE}/bin/strip
Shouldn't USE_BINUTILS automatically prefer all binaries from there to be
used, instead of the base system variants ?
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Mon, Oct 15, 2018 at 3:53 PM Ed Maste wrote:
> On Mon, 15 Oct 2018 at 07:13, Ed Maste 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
Index: lang/gcc48/Makefile
===
--- lang/gcc48/Makefile (revision 482165)
+++ lang/gcc48/Makefile (working copy)
@@ -33,6 +33,7 @@
SUFFIX= ${PORTVERSION:C/([0-9]+).([0-9]+).*/\1\2/}
USES= compiler cpe gmake iconv libtool makeinfo perl5 tar:bzip2
USE_BINUTILS= yes
+BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
USE_PERL5= build
SSP_UNSAFE= yes
Index: lang/gcc49/Makefile
===
--- lang/gcc49/Makefile (revision 482165)
+++ lang/gcc49/Makefile (working copy)
@@ -33,6 +33,7 @@
SUFFIX= ${PORTVERSION:C/([0-9]+).([0-9]+).*/\1\2/}
USES= compiler cpe gmake iconv libtool makeinfo perl5 tar:bzip2
USE_BINUTILS= yes
+BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
USE_PERL5= build
SSP_UNSAFE= yes
Index: lang/gcc5/Makefile
===
--- lang/gcc5/Makefile (revision 482165)
+++ lang/gcc5/Makefile (working copy)
@@ -34,6 +34,7 @@
SUFFIX= ${PORTVERSION:C/([0-9]+).*/\1/}
USES= compiler cpe gmake iconv libtool makeinfo perl5 tar:xz
USE_BINUTILS= yes
+BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
USE_PERL5= build
SSP_UNSAFE= yes
Index: lang/gcc6/Makefile
===
--- lang/gcc6/Makefile (revision 482165)
+++ lang/gcc6/Makefile (working copy)
@@ -35,6 +35,7 @@
SUFFIX= ${PORTVERSION:C/([0-9]+).*/\1/}
USES= compiler cpe gmake iconv libtool makeinfo perl5 tar:xz
USE_BINUTILS= yes
+BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
USE_PERL5= build
SSP_UNSAFE= yes
CFLAGS:= ${CFLAGS:N-mretpoline}
Index: lang/gcc6-devel/Makefile
===
--- lang/gcc6-devel/Makefile (revision 482165)
+++ lang/gcc6-devel/Makefile (working copy)
@@ -40,6 +40,7 @@
SUFFIX= ${PORTVERSION:C/([0-9]+).*/\1/}
USES= compiler cpe gmake iconv libtool makeinfo perl5 tar:xz
USE_BINUTILS= yes
+BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
USE_PERL5= build
SSP_UNSAFE= yes
Index: lang/gcc7/Makefile
===
--- lang/gcc7/Makefile (revision 482165)
+++ lang/gcc7/Makefile (working copy)
@@ -34,6 +34,7 @@
SUFFIX= ${PORTVERSION:C/([0-9]+).*/\1/}
USES= compiler cpe gmake iconv libtool makeinfo perl5 tar:xz
USE_BINUTILS= yes
+BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
USE_PERL5= build
SSP_UNSAFE= yes
CFLAGS:= ${CFLAGS:N-mretpoline}
Index: lang/gcc7-devel/Makefile
===
--- lang/gcc7-devel/Makefile (revision 482165)
+++ lang/gcc7-devel/Makefile (working copy)
@@ -40,6 +40,7 @@
SUFFIX= ${PORTVERSION:C/([0-9]+).*/\1/}
USES= compiler cpe gmake iconv libtool makeinfo perl5 tar:xz
USE_BINUTILS= yes
+BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
USE_PERL5= build
SSP_UNSAFE= yes
Index: lang/gcc8/Makefile
===
--- lang/gcc8/Makefile (revision 482165)
+++ lang/gcc8/Makefile (working copy)
@@ -34,6 +34,7 @@
SUFFIX= ${PORTVERSION:C/([0-9]+).*/\1/}
USES= compiler cpe gmake iconv libtool makeinfo perl5 tar:xz
USE_BINUTILS= yes
+BINARY_ALIAS= strip=${LOCALBASE}/bin/strip
USE_PERL5= build
SSP_UNSAFE= yes
CFLAGS:= ${CFLAGS:N-mretpoline}
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Mon, 15 Oct 2018 at 07:13, Ed Maste 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.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Mon, 15 Oct 2018 at 05:43, Antoine Brodin wrote: > > On Sat, Oct 13, 2018 at 11:26 PM Ed Maste wrote: > > > > Author: emaste > > Date: Sat Oct 13 21:26:07 2018 > > New Revision: 339350 > > URL: https://svnweb.freebsd.org/changeset/base/339350 > > > > Log: > > elfcopy: delete filter_reloc, it is broken and unnecessary > > > Hi, > > This commit broke lang/gcc* : 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? ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy
On Sat, Oct 13, 2018 at 11:26 PM Ed Maste wrote: > > Author: emaste > Date: Sat Oct 13 21:26:07 2018 > New Revision: 339350 > URL: https://svnweb.freebsd.org/changeset/base/339350 > > Log: > elfcopy: delete filter_reloc, it is broken and unnecessary > > elfcopy contained logic to filter individual relocations in STRIP_ALL > mode. However, this is not valid; relocations emitted by the linker are > required, unless they apply to an entire section being removed (which is > handled by other logic in elfcopy). > > Note that filter_reloc was also buggy: for RELA relocation sections it > operated on uninitialized rel.r_info resulting in invalid operation. > > The logic most likely needs to be inverted: instead of removing > relocations because their associated symbols are being removed, we must > keep symbols referenced by relocations. That said, in practice we do > not encounter this code path today: objects being stripped are either > dynamically linked binaries which retain .dynsym, or static binaries > with no relocations. > > Just remove filter_reloc. This fixes certain cases including statically > linked binaries containing ifuncs. Stripping binaries with relocations > referencing removed symbols was already broken, and after this change > may still be broken in a different way. > > PR: 232176 > Reviewed by: kaiw, kib, markj > Approved by: re (rgrimes) > MFC after:1 month > Sponsored by: The FreeBSD Foundation > Differential Revision:https://reviews.freebsd.org/D17519 > > Modified: > head/contrib/elftoolchain/elfcopy/sections.c Hi, This commit broke lang/gcc* : http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p482125_s339356/logs/errors/gcc48-4.8.5_9.log http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p482125_s339356/logs/errors/gcc49-4.9.4_8.log http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p482125_s339356/logs/errors/gcc5-5.5.0_5.log http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p482125_s339356/logs/errors/gcc7-7.3.0_5.log http://gohan2.ysv.freebsd.org/data/head-amd64-default-baseline/p482125_s339356/logs/errors/gcc8-8.2.0_1.log etc. Antoine ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
