Re: Plugins & GGC ie GTY

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

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