edges, plugins, and why they need a GC....

[Basile Starynkevitch <basile at starynkevitch dot net>]

Hello All,

I've got the following behavior in some MELT extension, but I am translating that as if it was a plain C plugin to GCC.

See https://groups.google.com/d/msg/gcc-melt/mHbiKcI8dZA/gCMT-943IjQJ for the original issue.

My colleague Emmanuel Haucourt wants to dump some control flow information into a file 
(to be later analyzed by a static analyzer ALCOOL detecting deadlocks in some multi-threaded 
[pseudo-] code)

So he decided to copy some edge pointers in his plugin pass inserted after the "phiopt" pass, 
these edge are copied to some static GTY-ed data (actually, to some MELT values, but from GCC
point of view, it is the same as some static GTY-ed data in his pass). 
Later another pass (or plugin event) tries to access these edges and crashes 
(because they have been forcibly destroyed).

However, edges are (unfortunately, and IMHO even wrongly) forcibly destroyed in the "expand" 
pass of file gcc/cfgexpand.c

So even if edges are GTY-ed, they get forcibly destroyed  (by "expand" pass calling cleanup_cfg 
which calls remove_edge which forcibly calls ggc_free on them, even if they are kept in some plugin 
GTY-ed static data.

It would be more correct to have the Ggc doing its job, and to avoid remove_edge calling ggc_free.... 
(which would be called anyway at  ggc_collect time).

Alternatively, (for those advocates of removing the GC instead of improving it)
every data in Ggc which is accessible from plugins should have a destroy event 
(what Gtk or Qt do in that respect could be inspiring) or plugin hook, 
to give plugins opportunity to clean their internal state, or use some smart pointer.

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***