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?

Hi David,

Thanks for your kind response!


在 2017年07月26日 21:43, David Malcolm 写道:

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?

I am using Fedora, and perhaps no RPM packages provides gengtype:
$ dnf repoquery --whatprovides gengtype

compare with
$ dnf repoquery --whatprovides *libgcc-c-api*
gcc-python-plugin-c-api-0:0.15-8.1.fc25.x86_64
...
so I have no idea how to auto-generated them at build time, instead I built GCC v4.6 and v6.3 https://github.com/xiangzhai/dragonegg/wiki/GGC please give me some hint, thanks a lot! 





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.
Yes! https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/Makefile#L196 




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*&)

Thanks for your hint :)






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


--
Regards,
Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]