[MLton] Re: PIC in amd64 assembly

[Wesley W. Terpstra]

On Thu, Aug 21, 2008 at 3:27 AM, Matthew Fluet <fluet at tti-c.org> wrote:

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


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.

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
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20080821/7a20ff67/attachment.htm