This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libffi return value convention bug
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Cc: java at gcc dot gnu dot org, <gcc at gcc dot gnu dot org>
- Date: Tue, 1 Oct 2002 15:55:00 -0400 (EDT)
- Subject: Re: libffi return value convention bug
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