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

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

Benjamin,

On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote:

> It's possible for the plugin to implement every possible dlsym entry  
> point
> and then farm the calls out to each individual script pass  
> internally, but
> since GCC is already going to have to maintain a list of callbacks,  
> it seems
> better to piggyback on the list GCC already maintains.

You've got a very good point.

> I agree that the current callback proposal seems overly generic.  
> Perhaps
> registering specific hooks into the pass manager and other plugin  
> targets
> makes more sense?
>
> typedef (void pluginpasshook)(tree t, void *data);
>
> /* implemented in the pass manager */
> register_plugin_event_after_pass(enum tree_pass, pluginpasshook fn,  
> void* data)

Hmmm, so could we unify tree_pass with the plugin_event structure from  
the API?
Like, we'd add a special "virtual" pass for GCC entry and shutdown,  
that sort of
thing.

> Then, plugins would implement only a single entry point. GCC would  
> inform
> the plugin of the arguments passed to it, and the plugin would  
> register
> callbacks to perform its actual work.
>
> /* implemented in the plugin */
> void gcc_plugin(const char *arguments);

This is nice.  One thing we do in our system is separate the arguments  
into
(non-unique) key-value pairs.  This makes arguments as close to regular
arguments as possible, in that they have both names and values.

> What kind of verisioning? I don't think that having a single  
> compiled plugin
> work with multiple versions of GCC should be a goal.

I mean versioning in the sense of "this hook used to provide one tree,  
now it
provides two."  I'm not talking about versioning the entire GCC API.

> I'm a little worried about the colon separator. Windows file paths may
> legally have colons. Is there some separator character (semicolon?)  
> which is
> not part of a path on any platform? Perhaps we shouldn't worry about  
> it
> since -rdynamic doesn't work on Windows anyway.

Agreed.  OS X paths can include semicolons, though.  This is something  
we
need to think about.

Sean