On Tue, 31 May 2011 10:52:39 +0200 Richard Guenther <richard.guent...@gmail.com> wrote:
> We could then, > reasoning with the plugin use, add additional langhooks encapsulating > functions such as c_register_pragma (possibly under a > lang_hooks.plugin substructure). Yes, that perhaps is a good way. But I never understood the lang_hooks and I had the impression it was becoming obsolete (or at least that GCC community wanted to have them less important than before). > The point I want to make is that we need to move away from the > current "plugins can access each and every non-local symbol from GCC". > Instead we need to expose a defined set of functions and structures, > and we can easily provide them through indirect dispatch (which opens > the possibility for a stable API even when the internal API changes - to > some extent at least). In another mail, I Basile proposed: >> An alternative could be that the short syntax >> -fplugin=name >> which for 4.6 means http://gcc.gnu.org/onlinedocs/gccint/Plugins.html >> -fplugin=`gcc -print-file-name=plugin`/name.so >> would really mean in the trunk & 4.7 >> -fplugin=`gcc -print-file-name=plugin`/cc1/name.so >> for cc1 and >> -fplugin=`gcc -print-file-name=plugin`/lto1/name.so >> for lto1 and so forth. >> This would permit a plugin developer to make a plugin name so that >> gcc -fplugin=name foo.c >> and >> gcc -fplugin=name -flto foo.c >> both works. The burden is then on the plugin developer. To which Richard probably responded with > I totally disagree with the proposed method of implementation And here, I don't understand why. The above trick I suggest is only a way to still tell -fplugin=name both to cc1 and to lto1 and have them do something more sensible than crash on a undefined symbol in a dlopen-ed plugin. Apparently, what Richard (& perhaps Diego) are implying (but this was written nowhere very clearly, and certainly is not documented at all in the plugin documentation, is that our plugin should disappear in their present form, and be replaced by at least two or three different kind of plugins. * the front-end plugin, which are source language specific * the middle-end plugin, which are approximately source language and target processor neutral (much as Gimple & Tree are), since they work mostly on Gimple (& related representations, like the control flow graph...) * perhaps the back-end plugin, which are target processor specific (and probably operates on RTL only, not on Gimple) I probably agree with that idea (but I don't feel it is so important), but it should be stated clearly as such. And to make it understandable to the naive user (not the plugin developer, just the guy running gcc or g++ without even knowing that cc1 or lto1 exist!) it should be documented, and * either the option -fplugin=name remains as it is, and then we need some machinery to make it work. My proposal of having -fplugin=name handled as -fplugin=`gcc -print-file-name=plugin`/cc1/name.so is a cheap answer. * or the option -fplugin= is removed, and we add two or three options -fplugin-frontend=... -fplugin-middleend=... -fplugin-backend=.... In any cases, if we replace the "single plugin" idea with the three-sorted plugin thing, we absolutely need to have a more robust way of starting the plugin. My preference would be that the plugin_init name (inside plugins) would be changed, perhaps to plugin_frontend_init, plugin_middleend_init, plugin_backend_init. But at least the plugin should absolutely and easily know if it was invoked from cc1, cc1plus, or lto1 programs. In http://gcc.gnu.org/ml/gcc/2011-05/msg00324.html I suggested a invoking_program field into struct plugin_gcc_version to give that information. It seems that Richard & perhaps Diego are implicitly referring to the mythical "modularization" goal of the GCC community. http://gcc.gnu.org/wiki/ModularGCC My feeling is that it remain an ideal wish, because I saw no significant patch going into that direction (and a patch adding modularity to GCC is necessarily a very big one). I also sadly feel that modularization of GCC cannot really happen, unless the community agree to work only on that (and to not add other disruptive changes during several months). In other words, for modularization to happen, we need a sort of stage 0 of several months, during which the only patches applied to trunk are that modularization effort, that is a huge rewriting phase during which no functionality are added. I don't believe that can practically happen (partly because I don't believe the corporations & institutions funding our work want that). Rewriting GCC more properly is much too disruptive an effort. And it might be related to its C++ -ization as dreamed by Ian and other nice guys. Back to plugins, if we really want several sort of plugins (that is front-end plugins, middle-end plugins & back-end plugins) we should state that clearly and document that. (I have no strong opinion on having several sorts instead of one kind of plugins. But if we do want that, we should state it very clearly.). Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
