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