ping^5: plugin directory

Basile Starynkevitch basile@starynkevitch.net
Wed Mar 24 21:55:00 GMT 2010


On Wed, Mar 24, 2010 at 02:39:25PM +0100, Matthias Klose wrote:
> On 24.03.2010 14:30, Richard Guenther wrote:
> >On Wed, Mar 24, 2010 at 2:18 PM, Matthias Klose<doko@ubuntu.com>  wrote:
> >>On 16.03.2010 09:04, Basile Starynkevitch wrote:
> >>[...]
> >>
> >>the patch in its current form doesn't search in a default location; only if
> >>-iplugindir is passed to the driver, a plugin directory is searched. If
> >>-iplugindir is not passed, plugins are not found. Is this intended?
> >>
> >>what is the motivation of adding an extra "libexec"? the values given to
> >>-iplugindir isn't really the plugin directory, but some kind of prefix.
> >>

For me, the -iplugindir is the way to pass the plugin directory, as
returned by the 
  gcc -print-file-name=plugin 
command documented on http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins 23.10 Building GCC plugins

So the -iplugindir is the mean by which the gcc program passes the
plugin directory (as defined above) to cc1 (& friends like
cc1plus...). In my view, the user don't use -iplugindir as an explicit
program argument to gcc (and if he dare do that, he is mostly on his
own; in particular gcc -print-file-name=plugin -iplugindir=/tmp don't
behave sensibly).

In a few words, there is some .spec tricks to pass the result of gcc
-print-file-name=plugin to cc1 & cc1plus thru -iplugindir= program
argument to cc1 & cc1plus ...

And the API to retrieve that directory from inside cc1 (in particular
from plugin code) is the proposed plugin_directory_name () function.

Notice that a fixed plugin directory could be useful to several
plugins. To be more specific, the MELT plugin need a small tree
hierachy (for keeping the commonly used MELT source *.melt files and
the generated C source *.c files and the generated *.so files), and
MELT explicitly needs the plugin include directory (since the MELT
plugin sometimes generate C code and compile it and dlopen it, all
this from the same cc1 process). I also believe that complex plugins
like TreeHydra could use a fixed plugin directory (I was thinking of a
place to store GCC dependent Javascript files for TreeHydra).

And this plugin directory (more precisely, plugin file tree, with
include/ and other subdirectories) is obviously dependent of the GCC
version. In particular, a system distributed in 2011 or 2012 will
probably have a plugin tree for gcc 4.5.1 and another plugin tree for
gcc 4.6.0.  For sure MELT will need different subtrees for GCC 4.5.1 & 4.6.0

In general, any plugin needing some configuration or state files will
want to keep them rooted at a place dependent of the version, host
system & target system of the involved GCC. The plugin directory (as
returned by gcc -print-file-name=plugin) is a convenient parent
directory for these kind of files.

Once we agree that the plugin directory (as returned by gcc
-print-file-name=plugin today, and as transmitted from gcc to cc1 thru
-iplugindir in my proposed patch) play a significant role and needs to
be queryable by plugins (thru a function like the
plugin_directory_name () I am proposing), since plugin includes are in
include/ there having commonly installed plugins .so files in libexec/
seems sensible to me. Or perhaps should it be better lib/ ? 
Do you want me to submit another patch with /lib instead of /libexec ?

> >>The default for the plugin directory should be
> >>
> >>  <exec_prefix>/<alias>/<version>/plugin
> >>
> >>Is it really necessary to append "libexec" to this path? It doesn't hurt,
> >>but now the exec prefix is encoded twice in the path.
> >

I am not sure to understand the question? Is it about $plugindir/lib/
versus $plugindir/libexec ?

> >If any we should simply search where we find crt*.o and friends.  No
> >need for yet-another-option.  Thus, simply lib/gcc/<alias>/<version>/.

We need a plugin directory, and MELT needs to be able to query
programmatically the result of gcc -print-file-name=plugin (and MELT
needs the plugin include subdirectory) and probably several plugins
needs a place and a convention to install their configuration or other
data. This place should depend of the GCC involved, much as the plugin
directory depends upon it.


> >Or maybe where we find cc1 and friends.
> 
> yes, I missed the "gcc/" subdir. No strong opinion on <exec_prefix> or <prefix>.
> Why not use the plugin subdir? Is this only meant to be used for the
> development files?

I am not sure to understand tha above question, but I hope to have
answered above.

> It would avoid errors for things like
> -fplugin=libstdc++ and other shared libs installed in this location.

I am not sure this is an error to avoid. -fplugin=libstdc++ won't
work, because libstdc++.so don't have any plugin_init () function. We
don't need to worry that much about bad -fplugin= arguments; they won't
work (no plugin_init, no plugin_is_GPL_compatible symbol).

By the way, perhaps our plugin function names should have GCC inside
them, so plugin_GCC_init & plugin_GCC_is_GPL_compatible .... instead
of plugin_init & plugin_is_GPL_compatible as the names dlsym-ed inside
the *.so of GCC plugins?
 

Thanks for reading, and for having replied.

Cheers


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***



More information about the Gcc-patches mailing list