Re: [plugins] [patch] Initial implementation of GCC plugin support

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

Le-Chun Wu wrote:
> Attached is the revised patch incorporating review comments from
> Joseph, Basile, and Zbigniew. 

> 	* configure: Regenerate.
>   
Maybe the regenerated files like configure should not be sent on the 
gcc-patches@ list till the patch is accepted... [the configure files 
make the diff file much longer]

> 	* gcc/toplev.c (compile_file): Call initialize_plugins.
> 	(do_compile): Call invoke_plugin_callbacks.
> 	(toplev_main): Call invoke_plugin_callbacks.

In my perception, plugin should be loaded & initialized before any 
source file is compiled. In particular, I see a possible need for 
plugins to be loaded & used without any source file compiled:

* in general, one could imagine that a plugin does something sensible 
without any source file compiled. For instance, it could print nicely 
some internal constants of gcc: one could imagine printing nicely 
various limits (eg SHRT_MIN from limits.h) or constants (eg 
GIMPLE_BINARY_RHS) thru a plugin for instance; one could perhaps even 
implement a compile server as a plugin.

* in MELT it is essential to invoke plugins (with arguments to them) 
without any source file, because the bootstrapped MELT translator works 
that way. MELT is not a GCC front-end, but a middle-end stuff,  even in 
the autosufficient task of translating MELT source to C, in particular 
of translating the MELT translator itself to C.

So I suggest to:

call initialize_plugins() outside of compile_file() or do_compile() but 
e.g. in toplev_main, probably after init_local_tick; there might be an 
issue with process_options() .... or alternatively call do_compile even 
without any input files... [this being probably better]

send an event just after plugin initialization, eg
 invoke_plugin_callbacks(PLUGIN_START_PROGRAM, NULL);

send an event from do_compile eg
 invoke_plugin_callbacks(PLUGIN_START_COMPILE, NULL);

send an event from compile_file, eg
 invoke_plugin_callbacks(PLUGIN_COMPILE_FILE, main_input_filename);

As a general remark, the plugin machinery should have a fairly extensive 
set of events before plugin code goes into trunk. Once plugin code is 
inside trunk, adding events would be much more painful!

We have not really discussed how to have plugins with ggc roots. I 
suggest adding that plugin code can at initialization time call
 plugin_register_ggc_root_table(struct ggc_root_tab[] roots_table);
This function probably has to be implemented inside gcc/ggc-common.c
I really think it is essential that plugins can have ggc roots and use 
GTY. In my view, plugins are barely usable without that essential feature!

I also suggest that the plugin patch contain an example of a useless 
plugin, eg a hello plugin, which just illustrate how to code a plugin. 
This plugin should only print something for each event...


Also, there is no call to dlclose yet? Do we want to dlclose properly 
each plugin? Do we require that plugins should free/unregister 
everything when finished?

By the way, I am still confused about who/when is a plugin patch 
committed to the plugin branch? What kind of approval does it need? Diego's?

Thanks a big lot to Le-Chun for his work. The progress is impressive!

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