I updated the page http://gcc.gnu.org/wiki/GCC_PluginAPI.
I cleaned up the formatting and added syntax coloring where
appropriate. I also changed the API to reflect the comments so far,
making it easier to register many callbacks at once while preserving
the ability to register callbacks dynamically as needed.
I volunteer to maintain this page. (That isn't to say no-one should
edit it, just that I'll keep it neat and make threads if there are
problems with the API.)
Sean
On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/31/09 10:06 PM, Sean Callanan wrote:
(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(...)
Mozilla currently uses only dlsym, and it's limiting. We have several
unrelated analysis scripts loaded throught the same binary plugin. The
binary plugin doesn't know in advance which passes the plugin wants
to see.
To implement this properly, we'd have to have which want to use the
same
callback.
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.
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)
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);
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.
What kind of verisioning? I don't think that having a single
compiled plugin
work with multiple versions of GCC should be a goal.
(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 like this better than the current solution: with the current
proposal it's
hard to tell which -fplugin-arg is supposed to go with which -fplugin.
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.
- --BDS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFJh0ZOSSwGp5sTYNkRAkn6AJ9e4zMwlZIrpdX7XUPDCfR0+56EYACfQW9f
vMxuuIrJyP6O4hjo9b+fVwo=
=OxHa
-----END PGP SIGNATURE-----
