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