[MLton] MLton broken FFI on AMD64???
Wesley W. Terpstra
wesley at terpstra.ca
Thu Feb 17 07:56:31 PST 2011
On Mon, Feb 14, 2011 at 7:07 PM, Matthew Fluet <matthew.fluet at gmail.com>wrote:
> 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.
That's a good point. Yuck.
[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.]
It's not just printf. I know of several platforms where system calls in C go
through some header magic-fu. There are #define's that rename things
depending on the _XOPEN_SOURCE / etc selection. Importing *any* symbols from
system libraries is rather error-prone.
Really, the best solution is to do like the MLton runtime: write your own
functions that do the C calls and import them instead. That works with the
system header defines/etc (and also dodges the varargs problem). The
overhead is quite low; gcc optimizes those proxy methods down to a single
branch instruction if the prototypes match.
> I suppose we could also be conservative here and always emit a varargs
What do you propose? Append a ", ..." to the end of the prototype?
I don't know of any architecture where it is a problem, but might passing a
variable argument and a normal argument differ on an input-by-input basis?
Imagine "void foo(int x, ...);" where passing the first integer goes as
32-bit on the stack but the second gets sign-extended to 64-bit. I don't
think anything forbids such a hypothetically evil ABI.
The other alternative is to simply not support _import-ing of varargs
Whatever we do, we should do it consistently across the codegens.
If we can't support C properly, then maybe varargs is a losing battle.
On the other hand, people rather expect 'printf' to work.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MLton