> 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.
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
