On Wed, 2017-07-26 at 15:19 +0800, Leslie Zhai wrote: > > 在 2017年07月11日 21:25, David Malcolm 写道: > > On Tue, 2017-07-11 at 10:50 +0800, Leslie Zhai wrote: > > > 在 2017年07月10日 22:16, David Malcolm 写道: > > > > On Sat, 2017-07-08 at 15:50 +0800, Leslie Zhai wrote: > > > > > Hi GCC developers, > > > > > > > > > > There was > > > > > > > > > > PLUGIN_REGISTER_GGC_CACHES > > > > > > > > > > pseudo-events for register_callback in GCC v4.x, but how to > > > > > migrate > > > > > it > > > > > for GCC v6.x? there is no PLUGIN_REGISTER_GGC_CACHES > > > > > deprecated > > > > > log > > > > > in > > > > > ChangeLog-201X nor git log plugin.h... please give me some > > > > > hint, > > > > > thanks > > > > > a lot! > > > > Trevor [CCed] removed it 2014-12-10 in r218558 > > > > (eb06b2519a361b7784b1807115fcb3dea0226035) in the commit: > > > > "remove gengtype support for param_is use_param, if_marked and > > > > splay > > > > tree allocators" > > > > > > > > The patch was here: > > > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02965.html > > > > > > > > where he talks about plugin migration. > > > Some plugins may need to add extra GGC root tables, e.g. to > > > handle > > > their own > > > @code{GTY}-ed data. This can be done with the > > > @code{PLUGIN_REGISTER_GGC_ROOTS} > > > pseudo-event with a null callback and the extra root table (of > > > type > > > @code{struct > > > -ggc_root_tab*}) as @code{user_data}. Plugins that want to use > > > the > > > -@code{if_marked} hash table option can add the extra GGC cache > > > tables > > > generated > > > -by @code{gengtype} using the @code{PLUGIN_REGISTER_GGC_CACHES} > > > pseudo-event with > > > -a null callback and the extra cache table (of type @code{struct > > > ggc_cache_tab*}) > > > -as @code{user_data}. Running the @code{gengtype -p @var{source > > > -dir} > > > -@var{file-list} @var{plugin*.c} ...} utility generates these > > > extra > > > root > > > tables. > > > +ggc_root_tab*}) as @code{user_data}. Running the > > > + @code{gengtype -p @var{source-dir} @var{file-list} > > > @var{plugin*.c} > > > ...} > > > +utility generates these extra root tables. > > > > > > > > > After diff gcc-6.3.0/gcc/testsuite/gcc.dg/plugin and > > > gcc-4.8.0/gcc/testsuite/gcc.dg/plugin > > > then migrate to GCC v6.x like this: > > > > > > > > > // Register our garbage collector roots. > > > #if GCC_MAJOR < 6 > > > register_callback(plugin_name, PLUGIN_REGISTER_GGC_CACHES, > > > NULL, > > > #else > > > register_callback(plugin_name, PLUGIN_REGISTER_GGC_ROOTS, > > > NULL, > > > #endif > > > const_cast<ggc_cache_tab > > > *>(gt_ggc_rc__gt_cache_h)); > > > > > > > > > and Trevor talks more about GTY((if_marked(XXX), param_is(XXX))) > > > htab_t > > > migrate to GTY((cache)) hash_table<MyHasher> such as: > > > > > > > > > #if (GCC_MAJOR < 6) > > > // FIXME: gengtype not support macro? > > > static GTY((if_marked("tree2int_marked_p"), param_is(struct > > > tree2int))) > > > htab_t intCache; > > > #else > > > struct intCacheHasher : ggc_cache_ptr_hash<tree2int> { > > > static inline hashval_t hash(tree2int *t2i) { > > > return tree_map_base_hash(&t2i->base); > > > } > > > > > > static inline bool equal(tree2int *a, tree2int *b) { > > > return a->base.from == b->base.from; > > > } > > > }; > > > static GTY((cache)) > > > hash_table<intCacheHasher> *intCache; > > > #endif > > > > > > > > > But I have no idea why gengtype does not support macro? > > > https://gcc.gnu.org/ml/gcc/2017-07/msg00045.html it just ignored > > > #if > > > (GCC_MAJOR < 6) still parse GTY((if_marked(XXX), param_is(XXX))) > > > htab_t > > > but not GTY((cache)) hash_table<MyHasher>... please give me some > > > hint, > > > thanks a lot! > > Unfortunately, gengtype is not a full parser for all of C++; IIRC > > it > > doesn't have any real support for the preprocessor. > > > > Maybe you can work around it in your plugin by providing two > > different > > headers, one for GCC_MAJOR < 6, the other for >= 6, and setting up > > the > > build so that gengtype is invoked on the correct header. (I know > > this > > is ugly, sorry). > > Right now I am using two different files: such as Cache4.cpp and > Cache6.cpp, and there is the same `struct GTY(()) tree2WeakVH` for > GCC > v4.x > https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Cache4 > .cpp#L99 > also for GCC v6.x > https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Cache6 > .cpp#L116 > > then gengtype auto-generated `struct ggc_root_tab` with Cache6.cpp > for > GCC v6.x > https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/include/dr > agonegg/gt-cache-6.3.inc#L1257 > it is of course different with Cache4.cpp for GCC v4.x > https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/include/dr > agonegg/gt-cache-4.6.inc#L970
It looks strange to me that this repository contains these per-gcc -version auto-generated .inc files; aren't these something that should just be created at build time? Near the end of: https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/Makefile I see that a make target that invokes gengtype. I think the best approach is to add logic to that Makefile so that that gengtype invocation either loads Cache4.cpp *or* Cache6.cpp, depending on the version of gcc being built against. gengtype doesn't support "#if" directives, so any conditional logic affecting which GTY things are seen needs to go in the Makefile, not in the .cpp files. > $ gcc -fplugin=/usr/lib64/dragonegg.so hello.c > cc1: error: cannot load plugin /usr/lib64/dragonegg.so > /usr/lib64/dragonegg.so: undefined symbol: > _Z9gt_ggc_mxRP11tree2WeakVH FWIW, demangling it via: echo _Z9gt_ggc_mxRP11tree2WeakVH | c++filt shows that it's: gt_ggc_mx(tree2WeakVH*&) > it is my fault! the symbol `_Z9gt_ggc_mxRP11tree2WeakVH` looks like > for > GCC v4.x, so I migrated the plugin to GCC v6.x wrongly? > https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Backen > d.cpp#L2662 > please give me some hint, thanks a lot! Hopefully the above helps; good luck. Sorry about gengtype. Dave > > Alternatively, maybe there's another way to solve this by > > rethinking > > the data structure. It seems like you have a hash table of some > > kind. > > Does the hash table "own" references to other GC-managed > > entities, or > > is it simply referenced *by* other GC-managed entities. Maybe > > there's > > another way to represent this data which would sidestep the issue. > > (I > > don't know, I'm just speculating). > > > > Hope this is helpful > > Dave >
