From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18253 invoked by alias); 11 Feb 2014 20:52:54 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18242 invoked by uid 89); 11 Feb 2014 20:52:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 11 Feb 2014 20:52:51 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 2611D5432CD; Tue, 11 Feb 2014 21:52:48 +0100 (CET) Date: Tue, 11 Feb 2014 20:52:00 -0000 From: Jan Hubicka To: Markus Trippelsdorf Cc: Rafael =?iso-8859-2?Q?Esp=EDndola?= , Renato Golin , Jan Hubicka , gcc Subject: Re: Fwd: LLVM collaboration? Message-ID: <20140211205247.GA28709@kam.mff.cuni.cz> References: <20140211022910.GA31962@atrey.karlin.mff.cuni.cz> <20140211185135.GA286@x4> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140211185135.GA286@x4> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-02/txt/msg00145.txt.bz2 > On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote: > > On 11 February 2014 12:28, Renato Golin wrote: > > > Now copying Rafael, which can give us some more insight on the LLVM LTO side. > > > > Thanks. > > > > > On 11 February 2014 09:55, Renato Golin wrote: > > >> Hi Jan, > > >> > > >> I think this is a very good example where we could all collaborate > > >> (including binutils). > > > > It is. Both LTO models (LLVM and GCC) were considered form the start > > of the API design and I think we got a better plugin model as a > > result. > > > > >> If I got it right, LTO today: > > >> > > >> - needs the drivers to explicitly declare the plugin > > >> - needs the library available somewhere > > > > True. > > > > >> - may have to change the library loading semantics (via LD_PRELOAD) > > > > That depends on the library being loaded. RPATH works just fine too. > > > > >> Since both toolchains do the magic, binutils has no incentive to > > >> create any automatic detection of objects. > > > > It is mostly a historical decision. At the time the design was for the > > plugin to be matched to the compiler, and so the compiler could pass > > that information down to the linker. > > > > > The trouble however is that one needs to pass explicit --plugin argument > > > specifying the particular plugin to load and so GCC ships with its own wrappers > > > (gcc-nm/gcc-ld/gcc-ar and the gcc driver itself) while LLVM does similar thing. > > > > These wrappers should not be necessary. While the linker currently > > requires a command line option, bfd has support for searching for a > > plugin. It will search /lib/bfd-plugin. See for example the > > instructions at http://llvm.org/docs/GoldPlugin.html. > > Please note that this automatic loading of the plugin only happens for > non-ELF files. So the LLVM GoldPlugin gets loaded fine, but automatic > loading of gcc's liblto_plugin.so doesn't work at the moment. Hmm, something that ought to be fixed. Binutils can probably know about GCC's LTO symbols it uses as a distniguisher. Is there a PR about this? > > A basic implementation to support both plugins seamlessly should be > pretty straightforward, because LLVM's bitstream file format (non-ELF) > is easily distinguishable from gcc's output (standard ELF with special > sections). I think it is easy even with two plugins for same file format - all ld need is to load the plugins and then do the file claiming for each of them. GCC plugin then should not claim files from LLVM or incompatible GCC version and vice versa. Honza > > -- > Markus