Re: PATCH: libffi vs. SPARC (again)

[Jeff Sturm <jsturm at one-point dot com>]

On Fri, 16 Nov 2001, Bryce McKinlay wrote:
> I was looking at this some more last night but got distracted. What I 
> don't understand is that if ffi_call doesn't promote sub-word return 
> values properly, why doesn't this test in ffitest fail on big-endian? It 
> doesn't fail on PowerPC.

Libffi does promote sub-word return values, regardless of rtype.  (It does
not assume arguments are similarly promoted by the caller, which seems
like an inconsistency.)

> natMethod.cc definatly looks buggy in the way it misuses "struct 
> jvalue", I'm just trying to figure out whether libffi is actually buggy 
> as well.

Yes.  _Jv_CallAnyMethodA passed a (struct jvalue *) to ffi_call, then
looks at (result->b).  It is the same as if it passed a (jbyte *) to
ffi_call.  In other words, _Jv_CallAnyMethodA assumes the return value is
_not_ promoted.

For that matter, the return value is not always 32-bit (i.e. "jint") as
Hans pointed out.  A "long" return value would suffice for most targets
including LP64, but not P64 (which Microsoft is using for their 64-bit OS,
unfortunately).  In any case, "double", "float" and "long long" need
special treatment, and we need a portable way to declare a return value
with the correct wordsize.

Jeff