This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 <> 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.
>'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,

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]