From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16255 invoked by alias); 31 Dec 2008 16:56:46 -0000 Received: (qmail 16245 invoked by uid 22791); 31 Dec 2008 16:56:45 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52,J_CHICKENPOX_82,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Dec 2008 16:56:09 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mBVGu7qX030395; Wed, 31 Dec 2008 11:56:07 -0500 Received: from zebedee.pink (vpn-12-21.rdu.redhat.com [10.11.12.21]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBVGu4xa012266; Wed, 31 Dec 2008 11:56:05 -0500 Message-ID: <495BA424.3030302@redhat.com> Date: Wed, 31 Dec 2008 16:56:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Craig Vanderborgh CC: java@gcc.gnu.org Subject: Re: TROUBLE with gcj 4.1.1 for arm-wince-pe References: <7a6473990812310843g72ac2965p36df4161c1b6aa50@mail.gmail.com> In-Reply-To: <7a6473990812310843g72ac2965p36df4161c1b6aa50@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2008-12/txt/msg00057.txt.bz2 Craig Vanderborgh wrote: > I am trying to bring up gcj 4.1.1 for arm-wince-pe, using binutils > 2.18.50. So far C, C++, and the binutils all seem to be working well > for arm-wince-pe (Windows CE 5 and Windows Mobile 5/6). The problems > I'm having are with our older libgcj. > > After taking a close look at libgcj/classpath 4.1.1, I decided to try > to reuse our older libgcj that's derived from gcc-3.3. This version > of libgcj has many fixes and enhancements we added, but more > importantly - its use results in much smaller executables. > > Porting our old libgcj-3.3 to the new 4.1.1 toolchain was a pretty > straightforward affair. Most of the compilation problems I had to fix > were due to illegal access of private class members and so on. After > a few days of porting work, I had our libgcj-3.3 compiling under > gcj-4.1.1. > > Then all hell broke loose. The linked test programs (e.g. > HelloWorld.java) run, but crash early on in _Jv_CreateJavaVM. An > examination of the situation shows that Java classes seen from the C++ > code (e.g. in prims.cc, natClassLoader.cc, natClass.cc and so on) are > really messed up. In one case, with java.lang.reflect.Modifier, I > observed that invoking the method Modifier.isAbstract(int) from C++ > with: > > java::lang::reflect::Modifier::isAbstract(foo); > > results in an ENTIRELY DIFFERENT METHOD being invoked. > > It's so screwed up that I am completely lost and need some input. Is > there some *elemental* reason why I can't port libgcj-3.3 to > gcj-4.1.1? Yes. We changed the ABI. > Do I have to change some things in the gcj 4.1.1 compiler > build to do this? Where should I look? The C++ header files are the most likely cause of this problem, but I'm sure there will be many more. The compiler knows a great deal about the structure of the runtime library. For what you're doing to work you'd have to find all the ABI changes and back-port them to the new compiler. What you're doing is more or less equivalent to ripping the telephone exchange out of Tokyo, dropping it into New York, and expecting it to work. Andrew.