[MLton] MLton broken FFI on AMD64???
matthew.fluet at gmail.com
Mon Feb 14 10:07:00 PST 2011
On Sun, Feb 6, 2011 at 8:38 PM, Matthew Fluet <matthew.fluet at gmail.com> wrote:
> On Fri, Feb 4, 2011 at 10:01 AM, Matthew Fluet <matthew.fluet at gmail.com> wrote:
>> Interestingly, it seems that MacOSX also demands that rax be set to
>> the the number of floating point parameters.
>> It seems that setting rax for every FFI call on AMD64 would be the
>> simplest solution.
> I committed a patch that always sets %rax to the number of XMMS
> registers passed for non-win64 AMD64 platforms; since %rax is caller
> save, this doesn't really affect register allocation and just incurs
> an immediate->register move instruction. That solved the issue on
> Linux and MacOSX (and presumably on other Unices).
BTW, it occurs to me that there isn't a good solution to this problem
with the C codegen. With the C codegen, MLton emits prototypes for
_import-ed functions that are derived from the type of the imported
function. The prototype assumes that the function is a non-varargs.
[There is a second issue with Henry's particular example, where the
MLton emitted prototype for printf disagrees with the prototype
exported by stdio.h, so one actually gets a compile error there.] I
suppose we could also be conservative here and always emit a varargs
The other alternative is to simply not support _import-ing of varargs functions.
More information about the MLton