Hello All,
(a meta question: do we need to reply-to all, or should the gcc@ list be
enough to discuss plugins, and the only destination of this interesting
discussion?).
Brendon Costa wrote:
Basile STARYNKEVITCH wrote:
But what about the trunk, which uses tuples?
I know nothing about the tuples and the trunk and whether tuples might
affect the way plugins work. Maybe others can comment...
To be honest i was more worried about how plugins will work with the
garbage collector and pre-compiled headers... I assume there is no
problem with this though since there are already a number of plugin
frameworks that exist that people report are working.
The MELT plugin is a bit specific about GGC, since in practice all the
gengtype-d code is inside gcc/basilys.c which is not a plugin itself
(but which, among other important things, deals with garbage collection
& dlopen-ing). I could imagine that the other plugin experiments did
similar stuff (meaning that they did not touch to gcc/ggc-common.h or to
the gengtype generator).
I'm not sure that pre-compiled headers (pch) should even work with
plugins. The reasonable solution is to disable them when any plugin is
used (what should happen if plugins are not used when the pch is
generated, but used when it is reloaded or viceversa; I don't know if
this situation is hard to detect. Likewise, what should happen when the
compilation of the header & the compilation of the source including the
pch both dlopen-ed a different variant of the "same" plugin?). At least,
having pch working with plugins should be postponed after the first
approved (i.e. merged into the trunk) plugin imlementation.
A generic plugin framework should certainly cooperate with GGC (the
garbage collector inside GCC). From what I understand (but I did'nt try
and might forgot important details) it should not be very hard (assuming
we do not care about dlclose-ing plugins); one should:
1. enhance the function ggc_mark_roots in gcc/ggc-common.c so that it
marks the GGC roots defined in the plugin. If the plugin is itself a
single PLUGIN.c source processed by gengtype, this means calling the
marking routines inside the gt_ggc_r_gt_PLUGIN_h array of ggc_root_tab
structures generated by gengtype & implemented in the gt-PLUGIN.h
generated file. Perhaps the plugin initialization routine (inside the
dlopen-ed plugin) should explicitly register some stuff to GGC.
2. more generally, enhance the code so that the equivalent of
gtype-c.h works with the plugins.
3. enhance the gengtype generator itself to be able to process a
plugin itself. This is perhaps more tricky since gengtype currently gets
its list of files to be processed in a very special (brittle & built-in)
way - it is not simple to pass the list of files as a program argument
to gengtype, currently it is generated at gengtype build time.
We should be careful about what happens when several plugins are loaded.
So there are some issues with GGC & plugins, but there should not be
very hard to solve (even if I don't claim it is very easy). I find the
issue of pass management & plugins more serious (because there is more
consensus to reach on what should be done).
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 mines, sont seulement les miennes} ***
