Hello All
Joern Rennecke wrote:
As long as you only need to GTY known types, you can avoid having extra GTY
roots by having all plugins share one GTY root in the plugin infrastructure;
this root can point to a list to which each plugin can add at will.
If you want new types, it gets ugly, because how can you independently
develop plugins and avoid collisions? An enum to describe a type
won't be enough anymore, unless you want to go te a really silly width and
statart doling out namespaces.
We don't need any enum to describe the type, unless the new type is
added into existing ones.
To be more concrete, let's suppose at first that a plugin FOO, which is
loaded by dlopen-ing FOO.so, uses GTY for some static roots. For
simplication assume FOO is only one C source file FOO.c which contains
therefore something like
struct someFOOstruct_st GTY(()) {
};
static GTY(()) struct someFOOstruct_st *someFOOptr;
...
#include "gt-FOO.h"
Now, I assume gengtype has been hacked to generate gt-FOO.h correctly
from FOO.c. I hope that is not an impossible hypothesis [1].
The generated file gt-FOO.h contains something like
const struct ggc_root_tab gt_ggc_r_gt_FOO_h[] = {...}
We just have to add some small code [2] into the ggc_mark_roots routine
of gcc/ggc-common.c to add the scanning using this gt_ggc_r_gt_FOO_h.
This is not a big deal. We should simply add a routine
ggc_register_plugin_root_tab(const struct ggc_root_tab*) that adds its
argument to some (static variable in gcc/ggc-common.c which is a) linked
list or vector, and have ggc_mark_root scan that list or vector by
adding a few lines there. We require plugin initializers to call
ggc_register_plugin_root_tab appropriatly, exactly like they do already
call register_callback etc...
Now there is the precompiled header issue. As an important remark, PCH
are not stable from one minor version of GCC to another (eg 4.3.1 to
4.3.2). As another remark, PCH are not very used. So my first attitude
would be simply that: any compilation involving a plugin cannot use or
generate any precompiled header. And PCH and plugins are already messy,
even without any additional GTY-ed roots, for the simple reason that
plugins are adding new code (the dlopen-ed one) into GCC whose behavior
is altered by the plugin.
If we really care about PCH with plugins (I really think we should not
care that much initially and leave the subject to future work), we
should write in the PCH file the full list of all the plugins, probably
their crypto-checksum (like md5 or sha1) to be sure that the plugin
loaded again is exactly the same as the plugin which was active when
generating the PCH, etc...
I believe we should not care about PCH and plugins at first,
independently of any GTY in plugins.
==============
Note [1]: the generated gt-FOO.h depends mostly of FOO.c, not of much
else. There is indeed some generated code (specific to each GTY-ed
struct) in gtype-desc.c, and we have to figure out how to generate it
inside gt-FOO.h (or maybe another plugin specific generated file like
gt2-FOO.h) and use it in plugins context. In gtype-desc.c there is
another struct ggc_root_tab gt_ggc_r_gtype_desc_c which we have to
somehow make more dynamic (I don't know how exactly yet), and also the
rtx_next array. Maybe we have to change the RTX_NEXT macro in rtl.h (but
I don't know what this macro is for).
Note [2]: the code to add into ggc_mark_roots is quite similar to
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00431.html; not a big deal,
very probably less than 50 lines.
=========================
I don't claim to have figured out all the details, but I don't see what is very
difficult in adding GTY-ed stuff in plugins (this is a feature
I really need to make MELT becoming a plugin) provided of course we
don't care yet about PCH & plugins, which is a difficult subject by
itself (even without any GTY inside plugins).
Comments (especially constructive comments) are welcome
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} ***
