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

[Sean Callanan <spyffe at cs dot sunysb dot edu>]

> 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.

(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.

(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.

(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).

Sincerely,
Sean Callanan