This is the mail archive of the gcc@gcc.gnu.org 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?


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).

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


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