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: Timothy Wall <timothy dot wall at verizon dot net>
- To: Mat Hostetter <mhostetter at tilera dot com>
- Cc: libffi-discuss at sourceware dot org
- Date: Wed, 19 May 2010 18:33:16 -0400
- Subject: Re: closure api return value types problem
- References: <4BBC38C1.9090909@redhat.com> <7uy6ffpofl.fsf@tilera.com>
On May 19, 2010, at 5:33 PM, Mat Hostetter wrote:
>>> * 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?
>
The example is wrong, and should use type ffi_arg rather than "int".
> -Mat