<div dir="ltr">On Thu, Aug 21, 2008 at 3:27 AM, Matthew Fluet <span dir="ltr"><<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, 6 Aug 2008, Wesley W. Terpstra wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As an aside to Matthew, that page indicates what I suspected about osx. You<br>
don't need the indirect symbols except for external symbols.<br>
</blockquote>
<br>
It seems that you need the indirection for external symbols (that come from shared libraries?), even when generating an executable. For example,<br>
changing<br>
call _L_printf_stub_0<br>
to<br>
call _printf<br>
in the output assembly for<br>
val p = _import "printf": string * int -> int;<br>
val _ = p ("%i\n\000", 10)<br>
yields<br>
<br>
[fluet@fenrir temp]$ mlton z.1.c z.0.S<br>
/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:<br>
_printf<br>
<br>
But, for example, changing<br>
call _L_Posix_IO_writeChar8Arr_stub_0<br>
to<br>
call _Posix_IO_writeChar8Arr<br>
links without problems.</blockquote><div><br>Yep. That's what I was expecting. I believe that i386-osx is the same as windows in this respect. Private/Public both don't need indirect access, but external always does (even for executables). The ghc page indicates that x86_64-darwin is significantly different, more like amd64-linux. I haven't found an official document for either of the darwin platforms, though, so this could be wrong.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It also reveals _symbol and _address are broken for access to external symbols; for example, consider:<br>
val ea = _address "cosf": MLton.Pointer.t;<br>
val w = MLton.Pointer.diff (ea, MLton.Pointer.null)<br>
val () = (print o concat) ["w = ", Word.toString w, "\n"]<br>
<br>
On x86-darwin:<br>
[fluet@fenrir temp]$ mlton -keep g -default-ann 'allowFFI true' z.sml<br>
/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:<br>
_cosf<br>
</blockquote></div><br>Yes. I haven't touched the symbol use in the i386 codegen yet. I expect it also has problems with _address on windows. The changes I made don't just fix things for libraries. On the windows platform (and it seems darwin too) you need more information than the old FFI supplied, even for executables.<br>
<br>The thing that I'm still hung up on for i386, though, is how to get the PC. The sysv abi docs for ia32 say to use 'call', but I can't. So again my question: why %ebp instead of %esp? I can't find any x86 instruction other than 'call' to get me the PC, so this is a real problem.<br>
<br></div>