This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: closure api return value types problem
- From: Mat Hostetter <mhostetter at tilera dot com>
- To: libffi-discuss at sourceware dot org
- Date: 19 May 2010 17:33:02 -0400
- Subject: Re: closure api return value types problem
- References: <4BBC38C1.9090909@redhat.com>
>> * I think you meant 'less than word' here (ppc64 has 64bit word and 32bit int),
>> otherwise libffi has even stranger architecture specific assumptions and we
>> need more fixes.
>Yes, I did mean "less than word".
I'm porting libffi to a new 64-bit platform, and I'm confused about
exactly how my 'ffi_call' is supposed to fill in subword return values.
The return_sc.c test does this:
ffi_arg rint;
...
args[0] = &ffi_type_schar;
...
ffi_call(&cif, FFI_FN(return_sc), &rint, values);
assert(rint == (ffi_arg) sc);
which implies that an ffi_call returning a signed char must actually
fill in by reference a full ffi_arg worth of bits, properly sign
extended. Since that's supposed to be the register size, that would
require a 64-bit store. OK, I can do that.
But if you look at the example that ships in the libffi info pages, it
does this:
int rc;
...
if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1,
&ffi_type_uint, args) == FFI_OK)
...
ffi_call(&cif, puts, &rc, values);
Note how the return value here is only 32 bits (int). So if my
ffi_call stores 64 bits (ffi_arg), as required to make the test suite
happy, it will overrun the stack in the simple example in the info pages.
Is the example wrong?
-Mat