This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?

在 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


pseudo-events for register_callback in GCC v4.x, but how to
for GCC v6.x? there is no  PLUGIN_REGISTER_GGC_CACHES deprecated
ChangeLog-201X nor git log plugin.h... please give me some hint,
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
tree allocators"

The patch was here:

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
   pseudo-event with a null callback and the extra root table (of type
-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
-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
-as @code{user_data}.  Running the @code{gengtype -p @var{source-dir}
-@var{file-list} @var{plugin*.c} ...} utility generates these extra
+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
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,
    register_callback(plugin_name, PLUGIN_REGISTER_GGC_ROOTS, NULL,

and Trevor talks more about GTY((if_marked(XXX), param_is(XXX)))
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
      htab_t intCache;
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;

But I have no idea why gengtype does not support macro? it just ignored #if
(GCC_MAJOR < 6) still parse GTY((if_marked(XXX), param_is(XXX)))
but not GTY((cache)) hash_table<MyHasher>... please give me some
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 also for GCC v6.x

then gengtype auto-generated `struct ggc_root_tab` with Cache6.cpp for GCC v6.x it is of course different with Cache4.cpp for GCC v4.x

$ gcc -fplugin=/usr/lib64/ hello.c
cc1: error: cannot load plugin /usr/lib64/
   /usr/lib64/ 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? 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

Leslie Zhai - a LLVM developer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]