Re: [plugin] Directory for plugins distributed with gcc

Re: [plugin] Directory for plugins distributed with gcc

[Diego Novillo]

[ Moved to gcc@ ]

On Wed, Jul 15, 2009 at 14:30, Olatunji Ruwase<tjruwase@google.com> wrote:

>  Has any decision being made on how plugins will be distributed with
> future releases. Is there going to be a plugins directory ?.
>  Thanks

We may want to produce some plugins that are useful for GCC
development and distribute them with the compiler, but in general I
don't think we should get in the habit of incorporating 3rd party
plugins in GCC.  This would be detrimental to one of the useful
properties of plugins (i.e., less code we need to maintain).

I set up a landing page where projects can register their plugins
(http://gcc.gnu.org/wiki/plugins).  My suggestion is to use that page
as the central plugins directory, with the assumption that we (GCC)
are not the maintainers of those packages.  We simply provide a link
to them.


Diego.

Re: [plugin] Directory for plugins distributed with gcc

[Olatunji Ruwase]

 Sorry that I wasn't very specific with my question. I m currently
wrapping up the conversion of
 mudflap into a plugin. Most of the required patches have being
approved and committed, so I was
 thinking ahead as to where the the plugin code will reside.
 Thanks for the information and the link

tunji

On Wed, Jul 15, 2009 at 11:43 AM, Diego Novillo<dnovillo@google.com> wrote:
> [ Moved to gcc@ ]
>
> On Wed, Jul 15, 2009 at 14:30, Olatunji Ruwase<tjruwase@google.com> wrote:
>
>>  Has any decision being made on how plugins will be distributed with
>> future releases. Is there going to be a plugins directory ?.
>>  Thanks
>
> We may want to produce some plugins that are useful for GCC
> development and distribute them with the compiler, but in general I
> don't think we should get in the habit of incorporating 3rd party
> plugins in GCC.  This would be detrimental to one of the useful
> properties of plugins (i.e., less code we need to maintain).
>
> I set up a landing page where projects can register their plugins
> (http://gcc.gnu.org/wiki/plugins).  My suggestion is to use that page
> as the central plugins directory, with the assumption that we (GCC)
> are not the maintainers of those packages.  We simply provide a link
> to them.
>
>
> Diego.
>

Re: [plugin] Directory for plugins distributed with gcc

[Diego Novillo]

On Wed, Jul 15, 2009 at 14:50, Olatunji Ruwase<tjruwase@google.com> wrote:
>  Sorry that I wasn't very specific with my question. I m currently
> wrapping up the conversion of
>  mudflap into a plugin. Most of the required patches have being
> approved and committed, so I was
>  thinking ahead as to where the the plugin code will reside.

Ah, this is a different issue.  What you are proposing is to take
mudflap out of GCC and convert it into a separate plugin.

I don't really have a strong opinion on mudflap in particular.  I
wouldn't mind making it a plugin, though.  What do other folks think?

In general I think spinning off modules/passes that are not used very
frequently (e.g. the tree browser) is a good idea since it reduces the
size of our code base.


Diego.

Re: [plugin] Directory for plugins distributed with gcc

[Joseph S. Myers]

On Wed, 15 Jul 2009, Diego Novillo wrote:

> In general I think spinning off modules/passes that are not used very
> frequently (e.g. the tree browser) is a good idea since it reduces the
> size of our code base.

Before moving something out to a plugin (if we think that is technically 
appropriate for the particular code in question) we should have a way to 
build code, set up to be built as a plugin, into the compiler so that the 
-fplugin options find the built-in code, in a way that does not depend on 
plugins otherwise being supported on the host system; maybe somewhere in 
the source tree to put sources for plugins that get built into the 
compiler, or a configure option to point to such sources.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [plugin] Directory for plugins distributed with gcc

[Paolo Bonzini]

On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
> Before moving something out to a plugin (if we think that is technically
> appropriate for the particular code in question) we should have a way to
> build code, set up to be built as a plugin, into the compiler so that the
> -fplugin options find the built-in code, in a way that does not depend on
> plugins otherwise being supported on the host system; maybe somewhere in
> the source tree to put sources for plugins that get built into the
> compiler, or a configure option to point to such sources.

It would be easy to switch from libdl to libltdl (which is independent 
from libtool, and can be built as a host module from the toplevel 
makefile), and use libtool -dlpreopen if this is desired.

Paolo

Re: [plugin] Directory for plugins distributed with gcc

[Joseph S. Myers]

On Wed, 15 Jul 2009, Paolo Bonzini wrote:

> On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
> > Before moving something out to a plugin (if we think that is technically
> > appropriate for the particular code in question) we should have a way to
> > build code, set up to be built as a plugin, into the compiler so that the
> > -fplugin options find the built-in code, in a way that does not depend on
> > plugins otherwise being supported on the host system; maybe somewhere in
> > the source tree to put sources for plugins that get built into the
> > compiler, or a configure option to point to such sources.
> 
> It would be easy to switch from libdl to libltdl (which is independent from
> libtool, and can be built as a host module from the toplevel makefile), and
> use libtool -dlpreopen if this is desired.

Unless libltdl can be statically linked in, using it is a bad idea for 
other reasons as previously discussed at length.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [plugin] Directory for plugins distributed with gcc

[Basile STARYNKEVITCH]

Joseph S. Myers wrote:
> On Wed, 15 Jul 2009, Paolo Bonzini wrote:
>
>   
>> On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
>>     
>>> Before moving something out to a plugin (if we think that is technically
>>> appropriate for the particular code in question) we should have a way to
>>> build code, set up to be built as a plugin, into the compiler so that the
>>> -fplugin options find the built-in code, in a way that does not depend on
>>> plugins otherwise being supported on the host system; maybe somewhere in
>>> the source tree to put sources for plugins that get built into the
>>> compiler, or a configure option to point to such sources.
>
> Unless libltdl can be statically linked in, using it is a bad idea for 
> other reasons as previously discussed at length.
>
>   
I am aware of these reasons (but I am not sure to agree with them; 
however, that is not my point here) against libltdl.

A possible trick would be to decide a convention, such as a plugin whose 
name starts with a dot, or contains a slash, is in fact a "builtin" 
plugin, always available (and its code is part of GCC core). Actually, 
there is a reason to do so, if some GCC code wants to use some plugin 
facility. For instance, the MELT branch, even when compiled as a branch 
(i.e. without being compiled as a plugin), does call register_callback 
internally. And currently, code can call register_callback without any 
plugin being actually loaded in. There is no check on the plugin name 
argument to register_callback.
Such a convention (on builtin plugins) does not need to be implemented 
by code. It could be just agreed upon and suitably documented.

A side effect of this would be perhaps to limit extra GCC -f... program 
flags, since we could make them as plugin flags to builtin plugins.


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

Re: [plugin] Directory for plugins distributed with gcc

[Paolo Bonzini]

On 07/15/2009 10:47 PM, Joseph S. Myers wrote:
> Unless libltdl can be statically linked in, using it is a bad idea for
> other reasons as previously discussed at length.

I know of no program that dynamically links to libltdl, actually.

Paolo

Re: [plugin] Directory for plugins distributed with gcc

[Rafael Espindola]

> In general I think spinning off modules/passes that are not used very
> frequently (e.g. the tree browser) is a good idea since it reduces the
> size of our code base.

I would go a  bit further.

One nice properties of plugins is that they have a more restrictive
API. That should help us to get the code a bit more maintainable.

Olatunji's work is a very nice example. For example, to make mudflap a
plugin he had to remove the occurrences of  "if (flag_mudflap)" and
make mudflap use the existing generic varpool.

>
> Diego.
>


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047