On Tue, May 31, 2011 at 7:17 PM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > 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.).
The way plugins work right now means that they can exactly do what a single frontend can do (be it cc1 or lto1) - access all functions that very frontend can access. As the set of functions differ between the frontends there cannot be a plugin that works for more than one frontend unless it restricts its use of functions to the subset that is common for those frontends. Which means that if a plugin wants to work with lto1 it has to restrict itself to a subset of functions available to lto1. I don't see a strong need for cross-language plugins with frontend function access - "meta plugins" such as MELT may be an exception, but they have to deal with that in a similar way we deal with frontends - have MELT++, MELTC, MELTFortran, etc. Iff we want to make plugins not randomly fail with -flto (which I think we _do_ want) then it is the plugin loader machines job to check for compatibility and either ignore (in case of lto1 maybe) or reject (in other cases) the plugin. So, I don't think a single MELT plugin that works with all frontend and at the same time has access to all frontend functions can work. If it could then we would have not 5 different frontend executables but a single one. Btw, you can also try using RTLD_LAZY instead of RTLD_NOW during dlopen of the plugin. It's also odd we load them with RTLD_GLOBAL, but well ... Richard. > > 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} *** >
