Fwd: LLVM collaboration?

Markus Trippelsdorf markus@trippelsdorf.de
Tue Feb 11 18:51:00 GMT 2014

On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote:
> On 11 February 2014 12:28, Renato Golin <renato.golin@linaro.org> 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 <renato.golin@linaro.org> 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 <inst>/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.

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


More information about the Gcc mailing list