On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote: > On 11 February 2014 12:28, Renato Golin <renato.go...@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.go...@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 sections). -- Markus
