This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: 2 stage BFD linker for LTO plugin
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Dave Korn <dave dot korn dot cygwin at gmail dot com>, Cary Coutant <ccoutant at google dot com>, GCC Development <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>
- Date: Thu, 20 Jan 2011 01:10:53 +0100
- Subject: Re: PATCH: 2 stage BFD linker for LTO plugin
- References: <AANLkTimNK6MyDq=1Z5CsUz4HxgeMKq4oG7nUM7W09UCb@mail.gmail.com> <AANLkTintqbVr0VjBfU+2k_iYM-E9ss8AEAnV8wyrGhJN@mail.gmail.com> <4CFD1C22.3090900@gmail.com> <AANLkTi=uSGqX8bi0ZLKoqnrqKEXNUof6LXemfX6Uf6uw@mail.gmail.com> <4CFD2933.6040800@gmail.com> <AANLkTinjJzQL4zmtJqaX=BUPX8vPz-aXfVvhkH5WYgYk@mail.gmail.com> <20101206232928.GA15607@bubble.grove.modra.org> <mcr39q14c0i.fsf@google.com> <mcrr5c9buv5.fsf@google.com> <AANLkTi=MzuK9x1cJ0Rp=xYjrzwvoorssgL7iLs2WDiWo@mail.gmail.com>
> On Wed, Jan 19, 2011 at 1:27 AM, Ian Lance Taylor <iant@google.com> wrote:
> > After some discussion on IRC, here is another approach to resolving the
> > issue with static linking and LTO.
> >
> > In this approach, the linker keeps track of all archives found after the
> > first file claimed by the plugin. ?If the plugin adds any object files,
> > and the object files refer to any symbols which are not yet defined,
> > then the linker will scan all the saved archives, in order, for a
> > definition of the symbol. ?If a definition is found, the linker will
> > pull in the appropriate object from the archive. ?If that object, in
> > turn, has any undefined symbols, the linker will pull in the appropriate
> > object from that archive or any later ones, and so forth. ?The linker
> > will honor --start-group/--end-group while rescanning.
> >
> > This should ensure that any previously unseen undefined symbols
> > introduced by the compiler are handled correctly. ?I think it is
> > appropriate to do this unconditionally when using plugins, as there is
> > no other reasonable way to handle undefined symbols in a file added by a
> > plugin.
> >
> > I've appended a patch to gold which implements this approach. ?The patch
> > is reasonably efficient and introduces no unnecessary file I/O. ?With
> > this patch to gold, and no change to gcc, the problematic -static test
> > cases which I know about pass. ?Also all the current lto.exp tests pass.
> > All those tests also pass if I edit the gcc LTO plugin to ignore the
> > -pass-through option, as that option is not necessary when the linker
> > implements this approach.
> >
> > As this patch does not require any changes to gcc, and fixes some cases
> > which are clearly bugs, I plan to commit this patch to binutils mainline
> > and to binutils 2.21 branch after a few days if I don't hear any
> > comments.
>
> Nice. Can we on the GCC side somehow identify Gold versions
> that support this and avoid -pass-through handling in that case?
> I'm not sure if with your patch the add_input_library or
> add_input_file plugin hooks are completely useless (and thus
> gold could simply ignore those at all).
Nice indeed. I think we should version tag the plugin interface and
handle this as version 1.1 or something.
We also want to add the PREVAILING_IRONLY_EXT and other bits that will
need some housekeeping of what plugin interface the linker provides.
Honza