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

[Jan Hubicka <hubicka at ucw dot cz>]

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

Honza