On 22/03/13 21:26, Jason Dagit wrote:
I had never heard of BEX/BEX64 errors before. Naturally I wanted to know
what it was. Perhaps others here have never heard of this as well? Just
in case, I'll share what I learned.
After a bit of digging I came across this:
http://technet.microsoft.com/en-us/library/cc738483(WS.10).aspx
I think that article is saying that windows has a policy to prevent
arbitrary buffers from being executed. Perhaps the RTS needs to do
something special on windows when it's allocating pages above a certain
address?
Of potential note is this section (I don't know the RTS at all, so maybe
it already takes care of the following):
What works differently?
Application Compatibility
Some application behaviors are expected to be incompatible with DEP.
Applications that perform dynamic code generation (such as just-in-time
code generation) and that do not explicitly mark generated code with
Execute permission might have compatibility problems with DEP.
Applications that are not built with SafeSEH must have their exception
handlers located in executable memory regions.
Applications that attempt to violate DEP will receive an exception with
status code |STATUS_ACCESS_VIOLATION (0xC0000005)|. If an application
requires executable memory, it must explicitly set this attribute on the
appropriate memory by specifying
|PAGE_EXECUTE|,| PAGE_EXECUTE_READ|,| PAGE_EXECUTE_READWRITE
|or|PAGE_EXECUTE_WRITECOPY| in the memory protection argument of the
|Virtual* |memory allocation functions. Heap allocations using the
|malloc()| and |HeapAlloc()|functions are non-executable.
Perhaps the problem is reproducible simply by forcing the 64bit windows
build of ghc to execute a thunk allocated above the 4 GB address range?
We explicitly call VirtualProtect() to set the execute bit on pages that
we need to execute code from, and have done for some time (Windows has
had DEP since XP SP2). In GHC this happens for foreign import
"wrapper", and when compiling a foreign call with GHCi, it doesn't
happen for ordinary thunks - the code for these is statically compiled
into the binary.
So the bottom line is I don't know what's going wrong here, and
unfortunately I don't have the time to investigate right now. Perhaps
Ian would able to look into it, as he did the Win 64 port.
Cheers,
Simon
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
