在 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/dragonegg/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/dragonegg/gt-cache-4.6.inc#L970
$ 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
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/Backend.cpp#L2662
please give me some hint, thanks a lot!
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
--
Regards,
Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/
�
