From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23926 invoked by alias); 12 Apr 2013 09:21:30 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 23916 invoked by uid 89); 12 Apr 2013 09:21:30 -0000 X-Spam-SWARE-Status: No, score=-8.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 12 Apr 2013 09:21:29 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3C9LRI5010117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Apr 2013 05:21:28 -0400 Received: from zebedee.pink (ovpn-113-41.phx2.redhat.com [10.3.113.41]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3C9LPIE009001; Fri, 12 Apr 2013 05:21:25 -0400 Message-ID: <5167D214.8030606@redhat.com> Date: Fri, 12 Apr 2013 09:21:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Bryce McKinlay CC: Bucher Fabio , "java@gcc.gnu.org" Subject: Re: ABI References: <17B34E365AFABC468216733E4B4CC754615925DC@mail-server.ntb.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00008.txt.bz2 On 04/11/2013 10:42 PM, Bryce McKinlay wrote: > On Thu, Apr 11, 2013 at 12:56 PM, Bucher Fabio wrote: > >> I am looking for the ABI the GCJ uses. Wich file contains the information a= =3D bout it? >> >> Is it in the sourcecode or exist a pdf-documantation? > > GCJ actually has two ABIs. The first, "old ABI" mimics the C++ ABI in > most respects: C++ code can call Java classes as if they were C++, > more-or-less. This results in a "brittle" ABI: any non-trivial change > to an underlying library requires re-compilation of binaries built > against it. > > The second, "BC ABI" (enabled with --indirect-dispatch) changes the > way things like method calls, field accesses, and class loading work > so that compiled code more closely adheres to the binary compatibility > rules of Java bytecode. Ah, good point. I presumed that the question was about the C++ ABI, since that's the only thing that's really externally visible. Andrew.