Re: Automatic lto plugin handling

[Markus Trippelsdorf <markus at trippelsdorf dot de>]

On 2012.10.04 at 09:53 -0700, H.J. Lu wrote:
> On Wed, Sep 19, 2012 at 3:23 AM, Markus Trippelsdorf
> <markus@trippelsdorf.de> wrote:
> > This patch introduces a new environment variable:
> > AR_NM_RANLIB_DEFAULT_PLUGIN
> >
> > It allows one to easily switch from one LTO plugin to another without
> > the need to use wrappers (scripts, gcc-ar, etc.).
> >
> > (For example if one wants to build a project with clang using link time
> > optimizations one simply points it to /usr/local/lib/LLVMgold.so.
> > If one wants to use gcc with slim LTO on simply points it to e.g.:
> > /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/liblto_plugin.so)
> >
> > An explicit "--plugin" command line switch overrides the environment
> > variable (so that existing wrappers keep functioning).
> >
> > If this looks acceptable it would be nice if someone could commit this,
> > because I don't have access.
> > Thanks.
> >
> > 2012-09-19  Markus Trippelsdorf  <markus@trippelsdorf.de>
> >
> > binutils/
> >         * ar.c (decode_options): Handle AR_NM_RANLIB_DEFAULT_PLUGIN
> >         environment variable.
> >         (ranlib_main): Likewise.
> >         * nm.c (main): Likewise.
> >
> 
> I would prefer to add automatic plugin support to binutils:
> 
> 1. Figure out gcc driver name and the plugin DSO name at configure time.
> 2. If --plugin is used without DSO name, call
> 
> popen ($gcc-driver -print-prog-name=$DSO)
> 
> to get plugin DSO path.

Picking up an idea from Jan Hubicka¹, this could be fully automated if
all compilers would drop their lto-plugin into a default plugin
directory.
Then ar/nm/ranlib could load these plugins one after the other, until
one of them claims the file in question.
If the linker later encounters files that are claimed by different
plugins, just error out (for the moment).

---
1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831#c28

-- 
Markus