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've fixed this in svn. The fix is not as simple as your proposal. Some \s
need to be escaped, but not others. It also apparently differs between MinGW
and cygwin. :-/

Please give the process.sml in svn/HEAD a whirl. Do you have cygwin also? I
would like to know how regression/spawn.sml fairs there.

> 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. 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 you can't make big allocations on the
stack. 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 as a stack-allocated
variable.

I've noticed that mingw (now?) also links to kernel32 on its own. So you
could edit the mlton script to not include -lkernel32. I've done a full
rebuild and regression test of MLton with -lkernel32 removed, and it worked
on my win64 toolchain. If it works for win32 as well, and you can confirm
that removing -lkernel32 resolves your FFI problems, I'll probably just
remove it in svn too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20080812/7e8ff597/attachment.htm