[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Libffi (git master) and guile (git master) on MIPS n32

From: rixed
Subject: Libffi (git master) and guile (git master) on MIPS n32
Date: Mon, 7 Feb 2011 22:41:50 +0100
User-agent: Mutt/1.5.20 (2009-06-14)


I encountered a bug running guile test-suite on MIPS n32. I think I understand
enough to explain it, yet I don't really know who to blame for the bug. I tend
to think that the error belongs to libffi but I'm unsure as I don't know how
one is supposed to use libffi.

The bug hits in this situation : guile uses libffi to call qsort from libc,
which itself call a comparison function defined in guile, via the
invoke_closure function of libguile that was defined as a libffi callback.

The return type defined by guile for this comparison function was
FFI_TYPE_SINT32 which looks correct with regard to qsort signature, and
consequently invoke_closure() pokes a signed int into the pointer to the
location of the return value (8 bytes were reserved for it by ffi_closure_N32,
which is also consistent with the n32 ABI).

Then we run into troubles : the return code of ffi_closure_N32 uses
"ffi_cif->flag >> 8*2" to learn what is the return type instead of the actual
ffi_cif->rtype. For mips, this ffi_cif->flag seams to be a simplified version 
of the
full type that just gives the size and alignment requirements of the value and
not its meaning. In the case at hand, the flag bits tell the return type is of
kind "FFY_TYPE_INT", ie a 64 bits word, and it reads that into the return 
register v0
and then return to the C caller (qsort).

The problem is : of these 64 bits, only the 32 lowest bits were set by
guile, and the upper 32 are desperately random. The n32 ABI says that the
return value is supposed to be stored in the 64 bits v0 register, with bit 32
extended onto the upper bits (sign extension from 32 to 64 bits). So, should
the guile invoke_closure function be aware that the 32 bits int return value
is expected to be sign extended and written as a 64 bits value? I doubt it;
it's certainly libffi's job to handle this. So should it be libffi's
ffi_closure_N32 that should only reads the lowest 32 bits of the return
location and sign extend it into v0? But to do this it should know that the
actual type stored in the 64 bits location is actually a 32 bits integer, so it
should use the ffi_cif->rtype instead of the mere ffi_cif->flags, which seams
to defeat the whole purpose of this flags.

So how am I supposed to fix this?
Someone with a previous experience with libffi on mips n32 please
provide some advice!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]