On Thu, Oct 20, 2011 at 10:56 AM, Jan Hubicka <hubi...@ucw.cz> wrote: >> On Thu, Oct 20, 2011 at 9:24 AM, Andi Kleen <a...@firstfloor.org> wrote: >> > From: Andi Kleen <a...@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 >
