From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17994 invoked by alias); 30 Dec 2010 02:26:13 -0000 Received: (qmail 17974 invoked by uid 22791); 30 Dec 2010 02:26:11 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_CX,TW_DC,TW_GC,TW_IB X-Spam-Check-By: sourceware.org Received: from mail-fx0-f47.google.com (HELO mail-fx0-f47.google.com) (209.85.161.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Dec 2010 02:26:05 +0000 Received: by fxm17 with SMTP id 17so10078815fxm.20 for ; Wed, 29 Dec 2010 18:26:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.86.196 with SMTP id t4mr502194fal.34.1293675962133; Wed, 29 Dec 2010 18:26:02 -0800 (PST) Received: by 10.223.102.76 with HTTP; Wed, 29 Dec 2010 18:26:02 -0800 (PST) In-Reply-To: <4D1B6955.9070001@caviumnetworks.com> References: <4D1A2017.3060605@caviumnetworks.com> <4D1B6955.9070001@caviumnetworks.com> Date: Thu, 30 Dec 2010 02:26:00 -0000 Message-ID: Subject: Re: NullPointerException throwed when running GCJ From: majia gm To: David Daney Cc: gcc-help@gcc.gnu.org, Java List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2010-12/txt/msg00012.txt.bz2 2010/12/30 David Daney : > On 12/29/2010 12:01 AM, majia gm wrote: >> >> 2010/12/29 David Daney: >>> >>> Adding java@... as this is where java questions are handled. >>> >>> On 12/28/2010 07:05 AM, majia gm wrote: >>>> >>>> Hi, everyone. >>>> >>>> I'm porting GCJ to a non-mainstream platform, which is a RISC machine >>>> with some similarity to ARM. >>>> The GCC I'm using is version 4.4.2. I start the porting from ARM's cod= e. >>>> >>> >>> There is quite a bit of work involved in getting libgcj running on a new >>> target. =A0One thing that is obvious from your stack trace is that the >>> stack >>> unwinding code is not decoding the instruction pointer properly. That >>> would >>> be one place to start. >>> >>> Unfortunatly, there isn't really one specific thing we can point you to. >>> =A0You will probably have to step through things with GDB and make sure >>> that >>> are the target specific code is doing the right thing. >>> >>> The boehm-gc may need porting as well. =A0Actually I might start with >>> boehm-gc, I think it has its own test suite, so it can be debugged >>> separately. >>> >>> Then look at all the target specific code for a known working target >>> (arm, >>> mips, x86, etc...) and try to verify that your target code functions >>> correctly. >>> >>> Good Luck, >>> David Daney >>> >>> >>> >>>> When running the GCJ on the target platform, it mentioned that the ECJ >>>> is needed. I don't know whether GCJ can live without ECJ, so I >>>> donwload the latest ECJ jar file and recompiled. >>>> >>>> When running GCJ to compile a JAVA source file, I got the following >>>> error. >>>> >>>> [root@localhost pxx]# gcj -C HelloWorld.java -v >>>> Using built-in specs. >>>> Target: unicore32-linux >>>> Configured with: /home/vhome/FengYi/pxx/mydir/gcc-4.4.2/configure >>>> --host=3Dunicore32-linux --target=3Dunicore32-linux --prefix=3D/usr >>>> --build=3Di686-redhat-linux-gnu --enable-clocale=3Dgnu --enable-shared >>>> --enable-threads=3Dposix --enable-__cxa_atexit --enable-languages=3Dja= va >>>> --with-gnu-ld --disable-libstdcxx-pch --disable-multilib >>>> --with-pkgversion=3DUC4_1.0_gama_20101228 >>>> Thread model: posix >>>> gcc version 4.4.2 (UC4_1.0_gama_20101228) >>>> COLLECT_GCC_OPTIONS=3D'-fsaw-java-file' '-C' '-v' >>>> '-fbootclasspath=3D./:/usr/share/java/libgcj-4.4.2.jar' '-g1' >>>> '-fsyntax-only' '-femit-class-files' '-S' '-o' 'NONE' '-shared-libgcc' >>>> =A0/usr/libexec/gcc/unicore32-linux/4.4.2/ecj1 HelloWorld.java -g1 >>>> -fbootclasspath=3D./:/usr/share/java/libgcj-4.4.2.jar -g1 -fsource=3D1= .5 >>>> -ftarget=3D1.5 -fzip-dependency /tmp/ccTF9EKh.zip >>>> Exception in thread "main" java.lang.ExceptionInInitializerError >>>> =A0 =A0at 0x1(Unknown Source) >>>> =A0 =A0at 0x3(Unknown Source) >>>> =A0 =A0at 0x5(Unknown Source) >>>> =A0 =A0at 0x5(Unknown Source) >>>> =A0 =A0at 0x5(Unknown Source) >>>> =A0 =A0at 0x5(Unknown Source) >>>> =A0 =A0at 0x5(Unknown Source) >>>> =A0 =A0at 0xffffffffffffffff(Unknown Source) >>>> =A0 =A0at 0x2(Unknown Source) >>>> =A0 =A0at 0xffffffffffffffff(Unknown Source) >>>> =A0 =A0at 0xffffffffffffffff(Unknown Source) >>>> Caused by: java.lang.NullPointerException >>>> =A0 =A0at 0x1(Unknown Source) >>>> =A0 =A0at 0x5(Unknown Source) >>>> =A0 =A0at 0x4(Unknown Source) >>>> =A0 =A0...9 more >>>> >>>> >>>> Could anyone give me some hints on how could this happen? >>>> I really appreciate you patience. >>>> >>> >>> >> >> Hi, David. >> >> Thank you for your reply. It's very nice of you. >> >> When metioned to the stack unwinding code, do you mean the file >> backtrace.h in libjava/sysdeps/arch? It seems some archs don't have >> this file. And ARM has this file, but seems it takes over little >> works. >> > > Before java can work, you need to make sure that your GCC can correctly > compile C and C++ code. =A0Specifically all GCC testsuite C and C++ tests= that > deal with exception handling must pass. > > libgcj as a normal part of its startup processing will throw and catch > several exceptions. =A0If the exception handling machinery is not working= you > will never get to your programs main() method. > > Before trying to get your own programs working, you should be able to run > the libjava testsuite and have the majority of the the tests pass. > > > >> Actually, the current status of my porting is as follows. I tried gij >> successfully on the target to interpret a simple class file >> HelloWorld.class which is compiled through a x86-gcj on a x86 machine. >> And the gcj on the target also works well to compile the source file >> HelloWorld.java into native executable file. But it fails to compile >> HelloWorld.java into HelloWorld.class through gcj on the target. My >> GCC version is 4.4.2, and the ecj I used is the latest. >> >> I found that when compiling Java sources into class file, the x86-gcj >> use the jc1 instead of ecj. >> The following two questions confusing me. Can gcj live without ecj? >> What's the difference between ecj and jc1? I googled and got little. >> > > ecj: .java -> .class > jc1: .class -> .s (assembly) > as: =A0.s -> .o (linkable object code) > ld: =A0.o -> executable program. > > The gcj driver program runs the required sequence of these to obtain the > requested result. > >> If you could give me some hints, I would really appreciate. >> >> Thank you. >> Gmmajia >> > > Hi, David. My target toolchain is cross build in a x86 machine. On my target machine there's only executables and libs of the toolchain, but no build tree. To run the testsuite, it seems I cannot use 'make check' when there's no build tree. Must I rebuild the toolchian on the target? Thank you.