Re: [Gc] Extend win32 static root handling to Cygwin targets.

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

Hans -

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
> diff.
> 
> bdwgc/ChangeLog:
> ...
> 
>   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?
> 
>     cheers,
>       DaveK
> 
> -- 
> (*) - 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...
Name: bdwgc-ivmai-240.diff
Type: application/octet-stream
Size: 14989 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20100319/ee0c932f/bdwgc-ivmai-240-0001.obj


More information about the Gc mailing list