[MLton] foreign-function calls on Intel Mac

[Matthew Fluet]

Relaying some discussion with John Reppy, regarding foreign-function calls 
on Intel Mac:


John asks:

>>> Presumably, there will also be a problem with the foreign-function 
>>> support?

Matthew replies:

>> Not necessarily.  Much of the Basis Library is implemented with 
>> foreign-function calls; the hyperbolic-trig and "pow" functions happened to 
>> be the only ones that we used the symbol name from the system library 
>> directly; now, abosolutely everything for the BL goes through 
>> statically-linked wrappers.
>> 
>> I guess there will be problems with _import-ing a function that happens to 
>> be in a dynamically linked library that requires the indirection.
>> 
>> I'm still curious if the C-codegen handled the math.sml regression test 
>> before I checked in the wrappers.  Because, with the C-codegen, we don't 
>> include the system header files; instead, we emit a function prototype into 
>> the C code.  So, in that situation, the generated code for math.sml would 
>> look like:
>> 
>> ...
>> Real64 cosh(Real64 x);
>> ...
>>   ... z = cosh(y); ...
>> ...
>> 
>> In which case, I don't know why gcc would know to compile the call to 
>> "cosh" via an indirection.
>> 
>> If you know of any good pointers on the MacOS dynamic-linking, I'd like to 
>> read up a little more to understand.

John responds:

> Right.  I was thinking about OpenGL, which is supported via a framework 
> (i.e., a dynamically loaded library).
>
> I think that the C compiler will always call external functions using 
> the indirection.  I think that the linker does some optimization of 
> indirect calls, but gcc always produces the stub function.
>
> There is some documentation for the feature on the PPC at
>
> 	http://developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> MachOTopics/Articles/dynamic_code.html#//apple_ref/doc/uid/TP40002528
>
> but I haven't seen anything for Intel yet.