[MLton] Re: PIC in amd64 assembly

[Matthew Fluet]

On Wed, 6 Aug 2008, Wesley W. Terpstra wrote:
> As an aside to Matthew, that page indicates what I suspected about osx. You
> don't need the indirect symbols except for external symbols.

It seems that you need the indirection for external symbols (that come 
from shared libraries?), even when generating an executable.  For example,
changing
         call _L_printf_stub_0
to
         call _printf
in the output assembly for
   val p = _import "printf": string * int -> int;
   val _ = p ("%i\n\000", 10)
yields

[fluet at fenrir temp]$ mlton z.1.c z.0.S
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: /tmp/fileoqR3a0.o has 
external relocation entries in non-writable section (__TEXT,__text) for symbols:
_printf

But, for example, changing
         call _L_Posix_IO_writeChar8Arr_stub_0
to
         call _Posix_IO_writeChar8Arr
links without problems.

Thus, it does seem to suggest that we could condition the use of indirect 
symbols based on the CFunction.SymbolScope.t of the called function.  See 
mkCCallLabel and mkSymbolStubs in x86-generate-transfers.fun.

It also reveals _symbol and _address are broken for access to external 
symbols; for example, consider:
   val ea = _address "cosf": MLton.Pointer.t;
   val w = MLton.Pointer.diff (ea, MLton.Pointer.null)
   val () = (print o concat) ["w = ", Word.toString w, "\n"]

On x86-darwin:
[fluet at fenrir temp]$ mlton -keep g -default-ann 'allowFFI true' z.sml
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: /tmp/fileY93JXr.o has 
external relocation entries in non-writable section (__TEXT,__text) for symbols:
_cosf