FW: [MLton] Working: MLton/Win64 toolchain

[Wesley W. Terpstra]

On Mon, Aug 11, 2008 at 4:02 PM, Nicolas Bertolotti <
Nicolas.Bertolotti at mathworks.fr>
>
> I built a cross compiler from Linux to Win64 and tried to port my product
> using it. So far, it seems that the pure SML code runs pretty fine on Win64
> but there still a few issues elsewhere.
>
> 1. Spawn
>
> I faced some troubles spawning child processes when the arguments contain
> some backslashes. Anyway, I am not sure this is related to the port as it
> also affects Win32 :
>
> I could notice that a new cmdEscape() function has been recently added to
> fix a common issue with _spawnve() on Windows when the arguments contain
> some white spaces. This function duplicates the backslashes which appears to
> be incorrect.
>
I'm looking into this. The fix is not as simple as your proposal. It seems
some \s need to be escaped, but not others. It also apparently differs
between MinGW and cygwin. :-/

> 2. FFI
>
> I am now facing a more complex issue with the foreign function interface.
> You will find attached a small example (30 lines of C code ; 2 lines of SML
> code) which reproduces the issue I am facing. In the example, when
> ffi_func() is called from SML code, it crashes (probably some kind of stack
> corruption) whereas it runs fine when it is executed from a C main().
>
This isn't MLton's fault per-se. If you link your test program with -O1 and
-lkernel32, you will see the exact same problem with a pure C program. eg:
gcc -Wall -O1 main.c ffi.c -o main.exe -lkernel32
with main.c:
void ffi_func();
int main() { ffi_func(); return 0; }
I have seen this before. With win64 big allocations on the stack seem flaky.
I had to hack around this for gmp as well. Why gcc gets this wrong, I don't
know. If you remove -lkernel32 or use -O2, the problem goes away. Probably
your best bet is to not use my_struct s as a stack-allocated variable. I've
noticed that mingw also links to kernel32 on its own (now?). So you could
edit the mlton script to not include -lkernel32, which also seems to fix it
for some reason.

I'm rebuilding MLton to see whether all regressions pass with -lkernel32
removed from the link line. If it works (and I'll have to check win32 as
well), I'll think about removing this from the mlton script by default.

PS. I couldn't reply to you directly. Check your mail server...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20080811/3f8d0148/attachment.html