This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Apparent thinko in closures.c causing GCC bootstrap failure on Cygwin
- From: Timothy Wall <twalljava at dev dot java dot net>
- To: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Cc: libffi-discuss at sourceware dot org, Java Patches <java-patches at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 30 Jun 2009 11:13:45 -0400
- Subject: Re: [PATCH] Apparent thinko in closures.c causing GCC bootstrap failure on Cygwin
- References: <4A4A024B.firstname.lastname@example.org> <19015FFA-2DB6-4825-8881-D0D492279470@dev.java.net> <4A4A2591.email@example.com>
On Jun 30, 2009, at 10:47 AM, Dave Korn wrote:
Timothy Wall wrote:
When compiling for windows, there shouldn't be any mmap/munmap
references at all. While cygwin may supply some version of these,
dlmalloc defines w32mmap/w32unmap which directly calls the
routines for windows when WIN32 is defined (which I believe is always
the case for the mingw compiler).
Apparently the cygwin build is defining macros differently than
-mno-cygwin (which is what I use for w32/w64), resulting in extant
references to mmap/munmap.
Yes, -mno-cygwin is *very* different from -mcygwin!
yeah, yeah, I know that in general. I was referring to a very narrow
When you use "-mno-cygwin" you are basically using a cross compiler
targeting MinGW. MinGW is built upon the MSVC runtime and only
functionality offered by the windows C library. Cygwin on the other
an entire POSIX-compatibility layer. So when you are using Cygwin
programming for a very different target environment, and the
appropriate macros to help.
Have you run the tests on a system with DEP enabled (System control
panel->Performance Options->Data Execution Prevention)? That's
the only place they'd fail if mmap isn't set up correctly. Prior
w64 patches the dlmalloc stuff never enabled the w32 mmap
so it was always using vanilla malloc for closures.
I haven't tried that yet. We have code in libgcc to make stack space
executable (so that trampolines don't get broken by DEP), but nothing
equivalent for heap space. ISTM we might want the Cygwin DLL to
space executable by default, I don't know; might have to suggest
that to the
mmap has explicit flags to ask for read/write/execute, which
presumably cygwin's DLL appropriately maps to the VirtualMalloc
equivalents somewhere down the line.
I'll take a look at the dlmalloc w32 functions and see whether it
sense to enable them on cygwin, or to use cygwin's POSIX mmap/
perhaps even to just enable the dlmmap/dlmunmap implementations.
consider the patch submission temporarily on hold.
While following the *nix variants and wrapping the mmap/munmap calls
with dlmmap/dlunmap (to add the exec flag) seems like the consistent
thing to do for cygwin, in this case cygwin is only going to insert
some translation code between the ultimate calls to VirtualAlloc/