From owner-svn-src-head@freebsd.org Tue Oct 16 07:26:27 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FFF210E4A08; Tue, 16 Oct 2018 07:26:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A014F7F0DE; Tue, 16 Oct 2018 07:26:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w9G7QEEB012929 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Oct 2018 10:26:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w9G7QEEB012929 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w9G7QE2m012928; Tue, 16 Oct 2018 10:26:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Oct 2018 10:26:14 +0300 From: Konstantin Belousov To: Antoine Brodin Cc: Ed Maste , Gerald Pfeifer , re , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r339350 - head/contrib/elftoolchain/elfcopy Message-ID: <20181016072614.GO5335@kib.kiev.ua> References: <201810132126.w9DLQ73C022496@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=1.5 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED,SORTED_RECIPS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 07:26:27 -0000 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 ?