[MLton] foreign-function calls on Intel Mac

[Matthew Fluet]

>> Right.  I was thinking about OpenGL, which is supported via a framework 
>> (i.e., a dynamically loaded library).

So, it doesn't appear that the native codegen can forgoe the Mach-O 
external function "calling covention".  We certainly want to support 
foreign-function calls to dynamically loaded libraries.

>> 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.


I would really like to see an "official" example for Intel.  It wouldn't 
be that hard to recreate the stub that John copied from gcc:

         .section __IMPORT,__jump_table,symbol_stubs,self_modifying_code
+pure_instructions,5
L_tanh$stub:
         .indirect_symbol _tanh
         hlt ; hlt ; hlt ; hlt ; hlt

But, I'd like to understand a bit more about what the different attributes 
are doing, what the linker expects/guarantees, etc.  For example, the 
x86-codegen will emit assembly code for distinct MachineIL functions into 
the same assembly file.  The most natural way of incorporating the Mach-O 
convention into the x86-codegen wouldn't carry the state of currently 
emitted stubs from the processing of one MachineIL function to the next. 
So, we would tend to generate assembly like:

...
          call _L124
...
         .section __IMPORT,__jump_table,symbol_stubs,self_modifying_code
+pure_instructions,5
_L124:
         .indirect_symbol _tanh
         hlt ; hlt ; hlt ; hlt ; hlt
...
          call _L986
...
         .section __IMPORT,__jump_table,symbol_stubs,self_modifying_code
+pure_instructions,5
_L986:
         .indirect_symbol _tanh
         hlt ; hlt ; hlt ; hlt ; hlt
...

I'd like to know that we can use an arbitrary label for the stub (i.e., 
that it doesn't need to be a prescribed mangling of the indirect symbol), 
that the linker will remove duplicates of the same symbol stub from within 
the same object file, etc.