Re: PATCH: libffi vs. SPARC (again)

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

On Wed, 14 Nov 2001, Anthony Green wrote:
> I'm surprised that this is necessary.  libffi should be changed if this is the
> case.

I think libffi could be changed.  But that may involve changing/testing
8 libffi ports, of which I could only do three...

> Please remind me what the problem was again.

Take a look at x86/sysv.S:

retint:
    cmpl  $FFI_TYPE_INT,%ecx
    jne   retfloat
    /* Load %ecx with the pointer to storage for the return value  */
    movl  24(%ebp),%ecx
    movl  %eax,0(%ecx)
    jmp   epilogue

This is where the code branches for byte-sized return values.  (See
ffi_prep_cif_machdep for return type mappings.)  The return value is
stored with a 'movl' instruction, which stores a 32-bit word.  This does
the wrong thing if the return value has fewer than 4 bytes allocated to
it.  There is no branch that performs a 'movb', thus no support to return
anything smaller.

Every other port is similar... here's sparc:

    cmp %i3, FFI_TYPE_INT
    be,a    done
    st  %o0, [%i4]  ! (delay)

Again, a 32-bit store.  If rtype is FFI_TYPE_SINT8, the return value will
not be written to [%i4], but [%i4+3], because sparc is big-endian.  So the
return value is lost, which is the symptom originally reported on the
mailing list.

Whether big- or little-endian we risk overflowing the return value buffer
(which may not affect libgcj, as the return value is a union type).

Since this behavior is partly documented in libffi/README I'd question
whether it was intended.

Jeff