From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23755 invoked by alias); 1 Dec 2007 12:08:37 -0000 Received: (qmail 23739 invoked by uid 22791); 1 Dec 2007 12:08:36 -0000 X-Spam-Check-By: sourceware.org Received: from smtp.nildram.co.uk (HELO smtp.nildram.co.uk) (195.112.4.54) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Dec 2007 12:08:30 +0000 Received: from firetop.home (85-211-136-23.dyn.gotadsl.co.uk [85.211.136.23]) by smtp.nildram.co.uk (Postfix) with ESMTP id 0C60F2B6FDC; Sat, 1 Dec 2007 12:08:25 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1IyR91-0001vw-O0; Sat, 01 Dec 2007 12:08:27 +0000 From: Richard Sandiford To: David Daney Mail-Followup-To: David Daney ,Java Patches , gcc-patches , rsandifo@nildram.co.uk Cc: Java Patches , gcc-patches Subject: Re: [Patch] libffi: Fixes for MIPS n32 ABI. References: <474E65AF.3040605@avtrex.com> Date: Sat, 01 Dec 2007 12:08:00 -0000 In-Reply-To: <474E65AF.3040605@avtrex.com> (David Daney's message of "Wed\, 28 Nov 2007 23\:09\:35 -0800") Message-ID: <874pf2ty6c.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2007-q4/txt/msg00041.txt.bz2 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. ...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