Re: [Patch] libffi: Fixes for MIPS n32 ABI.

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

David mentioned privately that the Java maintainers wanted a target
maintainer to look at this.  TBH, I don't think much of this is
target-specific, but:

David Daney <ddaney@avtrex.com> writes:
> The initial patches for mips64/n32 ABI support passed the libffi
> testsuite, however the java_raw_api support that is used by libjava
> still contained several problems.  This patch attempts to correct them. 
> With the patch applied we now have zero failures in the libjava
> testsuite (down from around 30).
>
> The problem was that libffi and libjava's interpreter use different
> union definitions to describe stack elements.  In the case of
> mips64/n32, these unions had different sizes (8 vs. 4 bytes).  This
> caused most interpreter method calls to fail.

...you're talking about ffi_raw vs. _Jv_word, right?  As far as
reviewing the patch goes, I'll sign off on the former being 8 bytes
and the latter being 4, if that helps.

Naively, rather than have an n32-specific definition of ffi_raw,
I'd have thought that we'd want some new target-controllable macro
that causes ffi_raw to be defined in the same way as _Jv_Word.
It sounds like this issue could affect other 64-bit targets
with an ILP32 ABI.

I don't really know much about the subtleties of the ffi_raw_*
vs. ffi_java_raw_* APIs though.  What does ffi_raw correspond to
when using the ffi_raw_* API (rather than the ffi_java_raw_* API)
on a !FFI_NATIVE_RAW_API target?  Is there any significance to the
structure's size?  Clearly ffi_raw as it stands is an accurate
description of the smallest possible n32 stack argument, whereas
the new ffi_raw would be more like half a stack argument.

As far as ffi_raw and java goes, the comment in java_raw_api.c says:

/* This defines a Java- and 64-bit specific variant of the raw API.	*/
/* It assumes that "raw" argument blocks look like Java stacks on a	*/
/* 64-bit machine.  Arguments that can be stored in a single stack	*/
/* stack slots (longs, doubles) occupy 128 bits, but only the first	*/
/* 64 bits are actually used.						*/

But why doesn't the ffi_java_raw_* API use a separate union that matches
the layout of _Jv_Word on all targets?  I realise that ffi_raw and _Jv_word
really must match if FFI_NATIVE_RAW_API, but must they match otherwise?
Even if backwards compatibility weren't a concern for some targets?
(I realise it _is_ a concern for targets that were supported in 4.2.)

Sorry for the barage of questions.  I'm just trying to get a feel
for the issues.

Richard