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