This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Apparent thinko in closures.c causing GCC bootstrap failure on Cygwin

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 appropriate
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 scope...

When you use "-mno-cygwin" you are basically using a cross compiler
targeting MinGW. MinGW is built upon the MSVC runtime and only supports the
functionality offered by the windows C library. Cygwin on the other hand is
an entire POSIX-compatibility layer. So when you are using Cygwin you are
programming for a very different target environment, and the compiler defines
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 likely
the only place they'd fail if mmap isn't set up correctly. Prior to the
w64 patches the dlmalloc stuff never enabled the w32 mmap equivalents,
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 render mmap'd
space executable by default, I don't know; might have to suggest that to the
Cygwin list.

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 makes more
sense to enable them on cygwin, or to use cygwin's POSIX mmap/ munmap, or
perhaps even to just enable the dlmmap/dlmunmap implementations. More later;
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/ VirtualFree.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]