From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15512 invoked by alias); 13 Feb 2020 08:15:48 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 15318 invoked by uid 89); 13 Feb 2020 08:15:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Received:Thu, liking, biarch, hardcoding X-HELO: mail-pg1-f193.google.com Received: from mail-pg1-f193.google.com (HELO mail-pg1-f193.google.com) (209.85.215.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2020 08:15:27 +0000 Received: by mail-pg1-f193.google.com with SMTP id b9so2534563pgk.12 for ; Thu, 13 Feb 2020 00:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=O3cBgDNzketMQhQ+LVqc/wQQERK2LBMzhUITSeQecX4=; b=a6DcNcfxZjncpWTHyyc6vc+B7ppnrK0JmRges3e9FiTgKkNeg9M/KVY5hjrHDKMNVz C0lr0Zgf26RbIWZXUwlt1/Sw9abe9HHEaO90JrkkSgEvpZKxe8RzqqVn2y9nTOJJztsJ ekw93rtnk7/rY6FJs012+j7OyJvnK00VFFDVIqfA7sk4NXFjGEHSqdcnrqBp09vSykrB wycCsSzCVXuQQ8qgH06Mmfmyv7M3OsCPAduzuJXh/0/i7cx6bm1gsYbWMjh0xnM1TNaK Mw98yZXJb70Sf3LplFEhXbYT3YwDOWgVzybFN12xSB6xldTIYUVrUbtJ9l6CJ6gLKoh8 E3pg== Return-Path: Received: from bubble.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id x10sm1966889pfi.180.2020.02.13.00.15.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Feb 2020 00:15:07 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id CFB828AD3B; Thu, 13 Feb 2020 18:45:03 +1030 (ACDT) Date: Thu, 13 Feb 2020 08:15:00 -0000 From: Alan Modra To: "H.J. Lu" Cc: Michael Matz , Binutils Subject: Re: [PATCH] Use GCC LTO wrapper to get real symbols from LTO IR objects Message-ID: <20200213081503.GF29647@bubble.grove.modra.org> References: <20200210142435.397899-1-hjl.tools@gmail.com> <20200210230156.GR5669@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00246.txt.bz2 On Tue, Feb 11, 2020 at 09:03:18AM -0800, H.J. Lu wrote: > On Tue, Feb 11, 2020 at 8:07 AM Michael Matz wrote: > > > > Hi, > > > > On Mon, 10 Feb 2020, H.J. Lu wrote: > > > > > > Wow, that's a lot of work to get proper symbol type. What happens if > > > > > > Very true. I couldn't come up with a better solution without changing > > > plugin API. > > > > Then, it should perhaps be changed? The cure without that (i.e. your > > patch) looks worse than the disease (temporary files, hardcoding path > > layouts, dependence on gcc installed) :-/ Yes, I expect to see complaints about the paths. You can also break the support in more creative ways. For example, when using CC="${gccdir}gcc/xgcc -B${gccdir}gcc/" and a more complex CXX to build binutils with a bleeding edge gcc. I also have cross compilers installed for a number of targets, and I used a trick to save building some 32-bit targets that have a 64-bit bi-arch compiler. Like this: $ cat /usr/local/bin/s390-linux-gcc #! /bin/sh case " $@ " in *" -m64 "*) p= ;; " -V "*) shift; p="-V $1 -m31 "; shift;; " -V"*) p="$1 -m31 "; shift;; *) p="-m31 ";; esac exec s390x-linux-gcc ${p}"$@" EOF After HJ's patch I see s390-linux +FAIL: Build liblto-12.a s390-linux +FAIL: Build liblto-14.a s390-linux +FAIL: Build liblto-15.a s390-linux +FAIL: PR ld/19317 (1) s390-linux +FAIL: Build libpr20267a.a s390-linux +FAIL: Build libpr20267b.a s390-linux +FAIL: Build pr22751.a s390-linux +FAIL: pr25355.o s390-linux +FAIL: Build libpr15146a.a s390-linux +FAIL: Build libpr15146d.a s390-linux +FAIL: Build libpr16746b.a Most of these are due to dejagnu not liking unexpected output, with the newly built ar spitting out errors like the following: Executing on host: sh -c {/home/alan/build/gas/s390-linux/ld/../binutils/ar -rc --plugin /home/local/bin/../libexec/gcc/s390x-linux/8.1.1/liblto_plugin.so tmpdir/liblto-12.a tmpdir/lto-12c.o 2>&1} /dev/null ld.tmp (timeout = 300) spawn [open ...] /home/local/bin/../lib/gcc/s390x-linux/8.1.1/../../../../s390x-linux/bin/ld: relocatable linking with relocations from format elf32-s390 (/tmp/cc32KkFydebugobjtem) to format elf64-s390 (/tmp/cc3YsYNydebugobj) is not supported collect2: error: ld returned 1 exit status lto-wrapper: fatal error: /home/local/bin/s390x-linux-gcc returned 1 exit status compilation terminated. bfd plugin: lto-wrapper failed Oh well, time to get rid of my hacky s390-linux-gcc. > > I know why you wrote the patch as is, but ... ugh. > > I think plugin API should be extended. In the meantime, we have a problem > to solve. -- Alan Modra Australia Development Lab, IBM