Defining a common plugin machinery
Basile STARYNKEVITCH
basile@starynkevitch.net
Thu Sep 18 11:06:00 GMT 2008
Hello Diego and all,
Diego Novillo wrote:
>
> After the FSF gives final approval on the plugin feature, we will need
> to coordinate towards one common plugin interface for GCC. I don't
> think we should be adding two different and incompatible plugin harnesses.
What exactly did happen on the FSF side after the last GCC summit? I
heard nothing more detailed than the Steeering Committee Q&A BOFS and
the early draft of some legal licence involving plugins. What happened
on the Steering Commitee or legal side since august 2008? Is there any
annoucement regarding FSF approving plugins?
> I am CCing everyone who I know is working on plugin features. Apologies
> if I missed anyone.
>
> I would like to start by understanding what the plugin API should have.
> What features do we want to support? What should we export? What
> should be the user interface to incorporate plugin code? At what point
> in the compilation stage should it kick in?
>
> Once we define a common API and then we can take the implementation from
> the existing branches. Perhaps create a common branch? I would also
> like to understand what the status and features of the different
> branches is.
The MELT plugin machinery is quite specific in its details, and I don't
believe it can be used -in its current form- for other plugins. It
really expects the plugin to be a MELT one.
From what I remember of the plugin BOFS (but I may be wrong), an easy
consensus seems to be that plugins should be loadable thru the command
line (probably a -fplugin=foo meaning that some foo.so should be
dlopen-ed), that they could take a single string as an argument (using
-fplugin-arg=bar) and that plugins add essentially new passes into
pass.c - I am happy with such a picture (and could fit MELT easily into
it; in its current form MELT is adding a few basilys*passes into
passes.c, each having a gate which try using a MELT closure somewhere so
is equivalent of testing if the pass is enabled.).
Albert Cohen & Grigori Fursin (both in CC) from INRIA have an
"Interative Compiler Interface" (a big patch to GCC) which could be
helpful to enhance this idea of extending the pass manager. AFAIK, they
also have some plugin facility (or maybe I am wrong). Perhaps some ideas
or code could be reused for plugins.
I have no idea if some general plugin code evolved recently, i.e. if
someone is actively working on it.
If someone is coding on plugins, please tell the gcc@ list.
Regards.
--
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
mailing list