[MLton] Re: [MLton-user] SVN r6941 MLton/MinGW32 and FFI

Wesley W. Terpstra wesley at terpstra.ca
Wed Nov 12 11:29:36 PST 2008


On Wed, Nov 12, 2008 at 6:46 PM, Matthew Fluet <fluet at tti-c.org> wrote:
> On Tue, 11 Nov 2008, Wesley W. Terpstra wrote:
>> One could imagine a default of public for MinGW and external for
>> darwin, but that seems pretty arcane.
>
> It may be arcane, but it can be justified --- this is effectively what
> previous versions of mlton did, albeit with some implicit help from the
> platform binutils.

It's also what gcc does. The gcc-approach works on every platform
MLton supports except win32 for address and variable accesses. This is
a definite plus, but since it only hides the details of the win32 case
without completely solving them, it's not clear to me that flipping
the default for this one platform is a great idea. For compatibility
with previous MLton versions it may make sense, but then we really
should have some sort of warning for imports with no scope, since the
default isn't something simple.

> [ a long summary ]

Yes, all correct.

> For Darwin, we produced assembly code for all functions as we now produce
> assembly code for 'external' functions.  However, the MachO linker was happy
> to patch, at link time, any function symbols that were satisfied by static
> libraries (i.e., symbols from the same DSO).
> However, this implicit help only comes with functions -- that is, symbols
> used in a call instruction (I think).  Symbols whose addresses are taken
> (i.e., via _address and a mov or lea instruction) do not get any implicit
> help (I think).

I think you have this confused... You can import any public symbol
using PLT-style indirections. Variables, functions, addresses,
whatever. It is just that I fixed MLton's handling of addresses and
variables on darwin at the same time I implemented symbol scopes. The
two changes were more-or-less unrelated.

> Nonetheless, it does seem as though 'external' is a better default.

Yes, it always works on darwin.

> I don't know if it is worth adding an 'ffiSymbolScope {error|ignore|warn}'
> MLB annotation to signal when FFI is used without an explicit symbol scope.

That sounds like a good idea.



More information about the MLton mailing list