Re: [Gc] Extend win32 static root handling to Cygwin targets.
ivmai at mail.ru
Fri Mar 19 11:55:22 PST 2010
Fri, 19 Mar 2010 15:34:43 +0000 письмо от Dave Korn <dave.korn.cygwin at googlemail.com>:
> Hi Hans and list,
> Hans, you may remember giving me some help with GCC PR42811 on the libjava
> list a month or so ago. This patch follows on from that investigation; Andrew
> Haley asked me to run the GC changes past you when he reviewed it, so I've
> up-ported it to your current CVS HEAD.
Looks good (and works).
I've checked in your patch (cygwin-mem-registration.diff) slightly modified (to suppress warnings).
should I add the suggested test files?
> The problem arising in the GCC PR is that none of the static data/bss areas
> of the main executable get registered with the GC. The libjava DLL registers
> its own data and bss, because it is the one that calls GC_init; but if it
> returns a pointer to an allocated object to the main executable (that it does
> not also retain a copy of in its own registered root areas), that pointer is
> then invisible to GC and it thinks the object is unreferenced and may release
> it and reallocate the space. I solve this by adding the win32 dynamic
> registration code into the mix(*), which should thoroughly take care of
> detecting all program and library data areas and malloc heaps.
> The attached patch switches the Cygwin target to use the same dynamic
> registration used on the native win32 targets. I've built it on cygwin and
> verified that the testsuite shows no regressions. I've also created a
> testcase that illustrates the problem, loosely based on the trace test. It
> FAILs with current HEAD and PASSes after applying the cygwin-mem-registration
> There is one slight hiccup that I'm not sure what to do about: I couldn't
> figure out how to get libtool to build a shared-but-not-installed library,
> because libtool assumes that any library you aren't planning to install will
> only be needed as a convenience (i.e. static archive) library. There might be
> a way round that, or you might want not to check in the testcase but just use
> it to verify the problem I've identified and fixed in the patch.
> Any comments or advice? Anything I should bear in mind when implementing
> this in the slightly-old version of the GC in libjava?
> (*) - Although it is win32-ish rather than posix-ish, it relies only on using
> VirtualQuery to determine properties of allocated memory ranges, which is a
> perfectly safe thing to do under cygwin. We still use posix interfaces for
> malloc/free/pthread stuff.
> ATTACHMENT: text/x-c (cygwin-mem-registration.diff)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 14989 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20100319/ee0c932f/bdwgc-ivmai-240-0001.obj
More information about the Gc