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

Leslie Zhai lesliezhai@llvm.org.cn
Thu Jul 27 04:32:00 GMT 2017


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/





More information about the Gcc mailing list