[PATCH] Add gcc-ar/nm/ranlib wrappers for slim LTO

[Richard Guenther]

On Thu, Oct 20, 2011 at 10:56 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Thu, Oct 20, 2011 at 9:24 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> > From: Andi Kleen <ak@linux.intel.com>
>> >
>> > Slim LTO requires running ar/nm/ranlib with the LTO plugin. The most
>> > convenient way to get this into existing Makefiles is using small
>> > wrappers that pass the plugin. This matches how other compilers
>> > (LLVM, icc) do this too.
>> >
>> > My previous attempt at using shell scripts for this
>> > http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02471.html
>> > was not approved. Here's another attempt using wrappers written
>> > in C. It's only a single wrapper which just adds a --plugin
>> > argument before calling the respective binutils utilities.
>>
>> Thanks for doing this.  How do they end up being used?  I suppose
>> Makefiles will need to call gcc-ar then instead of ar?  In which case
>
> Yes, it is what other compilers provide at the moment, too.
>
> In longer run, I would like to see binutils plugin machinery to be able
> to resolve this by itself for all installed compilers in the system.  This
> is bit tricky:
>  1) binutils already has default plugin search path.  We need to arrange our
>    plugin to install there
>  2) it is not realistic to expect exactly one linker plugin on the system.
>    LLVM/Open64/ICC eventually will want to provide their own plugins on
>    that search path
>  3) Either we will need to install plugin for every GCC release installed
>    or we will need to make our plugin resonably backward compatible.
>    This is probably not that big deal since the symbol table is rather simple
>    part of LTO machinery.  We broke compatibility in between 4.5/4.6 and 4.7,
>    but we probably could get more serious here.
>
>> I wonder if ...
>>
>> > The logic gcc.c uses to find the files is very complicated. I didn't
>> > try to replicate it 100% and left out some magic. I would be interested
>> > if this simple method works for everyone or if more code needs
>> > to be added. This only needs to support LTO supporting hosts of course.
>>
>> ;)
>>
>> ... using something like gcc --ar would be more convenient (as you
>> can then trivially share the find-the-files logic)?  Did you consider
>> factoring out the find-the-file logic to a shared file that you can re-use?
>
> Hmm, these alternatives would work with me.
> Bit ugly feature about gcc --ar is the fact that all options after --ar are
> passed to real ar and must be in the ar's syntax. That one is different from
> ours (and different from nm or ranlib's), so the formal description of how
> command line options works would get bit tricky.

Yeah, maybe use it as `gcc --ar`, thus make it print the found ar plus
the plugin argument ...

At least somehow sharing the file finding code would be nice, but I don't
want to block the patch in its current form if sharing it does complicate
things more than it simplifies them by not duplicating code.

Richard.

> Honza
>