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: Richard Sandiford <rsandifo at nildram dot co dot uk>
- To: David Daney <ddaney at avtrex dot com>
- Cc: Java Patches <java-patches at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 01 Dec 2007 12:08:27 +0000
- Subject: Re: [Patch] libffi: Fixes for MIPS n32 ABI.
- References: <474E65AF.3040605@avtrex.com>
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