Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)

[Taras Glek <tglek at mozilla dot com>]

Sean Callanan wrote:
> > 1- Agree on a common API and document it in
> >   http://gcc.gnu.org/wiki/GCC_PluginAPI
>
> So to get the ball rolling, here are some comments on the API as 
> documented:
>
> -
>
> (1) register_callback is an unnecessary API.  It's already possible to 
> use dlsym() to get a pointer to a symbol in a plug-in.  A plug-in 
> could export a function symbol corresponding to each hook it is 
> interested in; that way a plug-in would simply have things like
>
> void HOOK_PASS_MANAGER_SETUP(...)
>
> instead of needing to register that callback.  Equivalently, a global 
> data structure in the plug-in could map hook UIDs to function 
> pointers, giving the same effect.  This latter approach would provide 
> very elegant hook versioning.
Sounds good to me.
> (2) It would be very nice to be able to store trees between passes; 
> right now, our custom version of GCC has a separate garbage-collection 
> root for plug-ins so that they can store data between passes.
Cool, we'd like that too.
> (3) The -fplugin-arg argument is one way to do arguments.  We do it as
>
>   -ftree-plugin=/path/to/plugin.so:arg=value:arg=value:...
>
> We also have a magic argument called FILE that lets you load arguments 
> from a file.
I think it's a little more convenient to use a separate argument for 
plugin arguments. However we still end up having to split that up into 
multiple arguments in many case, so you are probably right here too.
> (4) We strongly support the user () GCC attribute.
>
> -
>
> As a second note, we have some debugging tools we could contribute as 
> soon as an API is fixed, including a GIMPLE visualizer with GDB 
> integration.
>
> We also have a file (called parameter.def) which formalizes the macros 
> that are valid for each type of GIMPLE tree node.  We use this .def 
> file extensively when handling trees in a generic way (such as for 
> pretty-printing).
Interesting. I took a completely opposite way of using GTY tags to 
reflect GIMPLE into JavaScript, which then pretty-prints GIMPLE(among 
other things) by porting the said macros to JS.

https://developer.mozilla.org/en/Treehydra

However any formalization should make my life easier.

Sean, I agree with you and I think others will too, so please go ahead 
and make your API modifications on the wiki

Taras