[MLton] Re: r6701

[Wesley W. Terpstra]

On Tue, Aug 19, 2008 at 7:42 PM, Matthew Fluet <fluet at tti-c.org> wrote:

> ld: foo.0.o has local relocation entries in non-writable section
>>> (__TEXT,__text)
>>>
>> That's because the i386 assembly isn't PIC, and osx requires PIC libraries
>>
> Well, I just wanted the compiler to build.  I don't have any need for MLton
> generated dynamically linked shared libraries on MacOS X.


Ahh, sorry the '.hidden' broke normal compilation on osx. That's my bad.
Thanks for the fix.

I'm currently in paper-deadline-before-vacation-pressure-mode, so I haven't
gotten to finishing the PIC for amd64 external calls or PIC of any kind for
i386. The amd64 stuff seems easy and I'll get to it soon. Like I discussed
with you earlier, i386 is quite a bit harder, particularly because %esp is
not usable in MLton assembly.

Why is %ebp used for the ML stack anyway? Since %esp gets pushed into
c_stackP, I'd have thought %esp would be perfectly fine for use as the ML
stack too. Would it be safe to push 4 bytes to the ML stack, if %esp were
pointing at it? ie, could I do this:
call tmp_label
tmp_label: pop %eax
mov gcState-tmp_label+someOffsetIntoGcState(%eax),%eax
to load a value out of the gcState array into %eax? The concern is that I
need to be sure that those 4 bytes at %esp are available. I don't really
understand how the limit checking of the ML stack works.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20080819/c7ccda30/attachment.html