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