This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] libffi: Fixes for MIPS n32 ABI.
- From: David Daney <ddaney at avtrex dot com>
- To: Java Patches <java-patches at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, rsandifo at nildram dot co dot uk
- Date: Sat, 01 Dec 2007 10:43:30 -0800
- Subject: Re: [Patch] libffi: Fixes for MIPS n32 ABI.
- References: <474E65AF.3040605@avtrex.com> <874pf2ty6c.fsf@firetop.home>
Richard Sandiford wrote:
> 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?
Correct.
> As far as
> reviewing the patch goes, I'll sign off on the former being 8 bytes
> and the latter being 4,
That was the state for n32 before the patch and the cause of the problems.
> if that helps.
>
Well, it helps it the sense that it clarifies my thinking and leads me
to think that the patch should be withdrawn.
Instead I think we want to define a java_ffi_raw union that agrees with
_Jv_word. All of the functions in java_raw_api would then be modified
to take java_ffi_raw* parameters.
> 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.
>
Presumably there are users of the ffi_raw API and we cannot change the
definition of the ffi_raw union.
> 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?
That is what my new patch will do.
> 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
>