Sean Callanan wrote:
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.
I'd like to warn against mixing pass manager passes and plugin
callbacks. The pass manager needs a host of API improvements to be able
to enumerate/reorder/remove/etc passes.
However, the task of the plugin api should be to load outside code into
GCC. The rest of the API improvements are general GCC improvements that
happen to mainly benefit plugins.
Once a plugin is loaded, then it could setup the necessary pass-manager
configuration.
Regarding versions: I think it's crazy to be passing a version in every
single function call. The plugin should check the gcc version it is
being loaded into on startup and bail if it doesn't match.
Taras
