This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: closure api return value types problem


>> * 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]