libffi return value convention bug

Tue Oct 1 12:55:00 GMT 2002

On Tue, 1 Oct 2002, Ulrich Weigand wrote:
> So, I cannot implement ffi_call to satisfy at the same time both
> requirements on a 64-bit big endian machine. Any suggestions?

This was discussed (but not resolved) when I posted my SPARC V9 closure
patches for comment.
http://gcc.gnu.org/ml/java-patches/2002-q3/msg00036.html
http://gcc.gnu.org/ml/java-patches/2002-q3/msg00047.html
Note that java_raw_api.c tries to handle the mismatch between _Jv_word and
ffi_arg unions, but the existing code doesn't extend nicely to 64-bit or
big endian targets.
Afterwards I realized my patch may break powerpc, which I could not test.
> (B.t.w. why aren't the return value pointers handled just the same as
> the argument pointers, i.e. as void pointers interpreted to point to
> exactly the type described by cif->rtype? That sure would simplify
> the issue ...)

No idea. Alpha does just that, but the powerpc and SH big endian ports
seem to expect that char/short values are returned in a (int *).
While balancing portability and efficiency, I suspect the libffi code
ended up with some of both :-(
Hans Boehm suggested the libffi API could be divided into "cooked", "raw"
and "java" models. I don't think anyone has acted on his suggestion:
http://gcc.gnu.org/ml/java-patches/2002-q3/msg00040.html
Jeff