[MLton] Shared libraries for MLton

[Matthew Fluet]

> > >>     o NOTE: The first garbage collection provokes a crash, the
> > >>             error is probably to be found here.
> > > 
> > > That is unfortunate.
> > 
> > Indeed. Fixing it requires a bit more knowledge of the inner
> > workings of MLton than I have at the moment, so I hope someone
> > can point in the right direction.
> 
> As best I can make out, the problem is that the Thread_returnToC primitive 
> does not leave the ML stack in a good state.  Apparently, we don't do as 
> many assertions and don't make as many assumptions about the 
> callFromCHandler thread as we do about the currentThread.  And, whatever 
> bad state the callFromCHandler thread is in, it is fixed when transfering 
> control to an _export-ed ML function before a GC occurs when the 
> callFromCHandler thread as been switched to.

Interestingly enough, if I add

	GC_switchToThread (&gcState, gcState.callFromCHandler, 0);	\

to the end of init_function in c-main.h, then I can get Jens' example to 
compile and run without any segfault.  As a bonus, this also works for the 
bytecode codegen, though the native x86 codegen has a mysterious segfault 
when trying to return to init_function.

However, I note that compiling the shared library with -debug true, 
thereby linking with a runtime with more assertion checks, then there is 
an assertion failure:

gc.c:480: assert(0 <= index and index < s->frameLayoutsSize) failed.

which points to a stack in a bad state.

As to why returnToC from the main thread leaves the stack in a bad
(segfaulting) state, but returnToC from an _export-ed function leaves the 
callFromCHandler stack in a good enough state to make another C-call to an 
_exported function, I don't know.

I note that the C and bytecode codegens treat Thread_returnToC as 
primitives, while the x86 codegen treats it a a C-call.  The interesting 
thing about the x86 codegen is that because Thread_returnToC is treated as 
a C-call (translated in ssa-to-rssa.fun), then the resulting C-call is 
marked as a runtime call, so the appropriate frame markers are inserted. 
On the other hand, the C and bytecode codegens don't do anything special 
to mark the stack at the point of a Thread_returnToC primitive.