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


> >> If you came up with a small self-contained test case it'd help a lot.
> > 
> > What kind of test you would like to see?
> > The tests are in libffi tree and they all work correctly (even on ppc64):
> > testsuite/libffi.call/cls_ushort.c
> > testsuite/libffi.call/cls_float.c
> > testsuite/libffi.call/cls_ulonglong.c
> 
> Right, so there is no problem, then.  I thought you said there was a
> problem with ghc that you wanted to solve.
I'll answer to this slightly later [1].

> > But! The thing I don't understand is why libffi treats ushort, uint
> > retval types (and _only_ retval types!) so specifically?
> 
> I think this is just because of the common (universal?) C ABI
> convention that integer typed return values of rank less than int are
> returned as a whole word, suitably sign- or zero-extended.  It need
> not have been done that way.

The thing is:
* it's _very_ unintuitive (and not only for me) as that closure callback
   (with args and resp parameters) is meant to be convention agnostic
> integer typed return values of rank less than int are
> returned as a whole word
* 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.

[1] Initial ghc assumption was to store result the same way as
arguments are passed. Without any promotions. I had to add those
promotions for intergal types less, than a word.

I was impressed by the fact: client has to know about magic ffi_arg
argument type. He has to include ffi.h header, has to detect what kind
of type he wants to return and build it properly.

I started this discussion to clarify whether this ABI is absolutely inevitable
or it just was done in such an ug^W peculiar way at random.

So yes, ghc does not have known libffi problems right now.
I wonder what ABI assumptions will be for non cconv closures. Will we have
to add even more workarounds just to call libffi properly?

Thank you for your response!

> Andrew.
>

-- 

  Sergei

Attachment: signature.asc
Description: PGP signature


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