Re: Defining a common plugin machinery

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

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} ***