From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16405 invoked by alias); 1 Oct 2002 19:55:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16376 invoked from network); 1 Oct 2002 19:55:14 -0000 Received: from unknown (HELO ops2.one-point.com) (216.234.116.146) by sources.redhat.com with SMTP; 1 Oct 2002 19:55:14 -0000 Received: from localhost (jsturm@localhost) by ops2.one-point.com (8.11.6/8.11.6) with ESMTP id g91Jt1S17454; Tue, 1 Oct 2002 15:55:01 -0400 Date: Tue, 01 Oct 2002 13:01:00 -0000 From: Jeff Sturm To: Ulrich Weigand cc: java@gcc.gnu.org, Subject: Re: libffi return value convention bug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg00050.txt.bz2 On Tue, 1 Oct 2002, Ulrich Weigand wrote: > So, I cannot implement ffi_call to satisfy at the same time both > requirements on a 64-bit big endian machine. Any suggestions? This was discussed (but not resolved) when I posted my SPARC V9 closure patches for comment. http://gcc.gnu.org/ml/java-patches/2002-q3/msg00036.html http://gcc.gnu.org/ml/java-patches/2002-q3/msg00047.html Note that java_raw_api.c tries to handle the mismatch between _Jv_word and ffi_arg unions, but the existing code doesn't extend nicely to 64-bit or big endian targets. Afterwards I realized my patch may break powerpc, which I could not test. > (B.t.w. why aren't the return value pointers handled just the same as > the argument pointers, i.e. as void pointers interpreted to point to > exactly the type described by cif->rtype? That sure would simplify > the issue ...) No idea. Alpha does just that, but the powerpc and SH big endian ports seem to expect that char/short values are returned in a (int *). While balancing portability and efficiency, I suspect the libffi code ended up with some of both :-( Hans Boehm suggested the libffi API could be divided into "cooked", "raw" and "java" models. I don't think anyone has acted on his suggestion: http://gcc.gnu.org/ml/java-patches/2002-q3/msg00040.html Jeff