From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23612 invoked by alias); 30 Dec 2010 17:38:37 -0000 Received: (qmail 23202 invoked by uid 22791); 30 Dec 2010 17:38:34 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_CX,TW_DC,TW_GC,TW_IB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Dec 2010 17:38:24 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6,7,2,8378) id ; Thu, 30 Dec 2010 09:39:09 -0800 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Dec 2010 09:38:23 -0800 Received: from dd1.caveonetworks.com ([12.108.191.236]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Dec 2010 09:38:23 -0800 Message-ID: <4D1CC38E.4040804@caviumnetworks.com> Date: Thu, 30 Dec 2010 17:38:00 -0000 From: David Daney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: majia gm CC: gcc-help@gcc.gnu.org, Java List Subject: Re: NullPointerException throwed when running GCJ References: <4D1A2017.3060605@caviumnetworks.com> <4D1B6955.9070001@caviumnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2010-12/txt/msg00013.txt.bz2 On 12/29/2010 06:26 PM, majia gm wrote: > 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 code. >>>>> >>>> >>>> There is quite a bit of work involved in getting libgcj running on a new >>>> target. One 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. >>>> You 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. Actually 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=unicore32-linux --target=unicore32-linux --prefix=/usr >>>>> --build=i686-redhat-linux-gnu --enable-clocale=gnu --enable-shared >>>>> --enable-threads=posix --enable-__cxa_atexit --enable-languages=java >>>>> --with-gnu-ld --disable-libstdcxx-pch --disable-multilib >>>>> --with-pkgversion=UC4_1.0_gama_20101228 >>>>> Thread model: posix >>>>> gcc version 4.4.2 (UC4_1.0_gama_20101228) >>>>> COLLECT_GCC_OPTIONS='-fsaw-java-file' '-C' '-v' >>>>> '-fbootclasspath=./:/usr/share/java/libgcj-4.4.2.jar' '-g1' >>>>> '-fsyntax-only' '-femit-class-files' '-S' '-o' 'NONE' '-shared-libgcc' >>>>> /usr/libexec/gcc/unicore32-linux/4.4.2/ecj1 HelloWorld.java -g1 >>>>> -fbootclasspath=./:/usr/share/java/libgcj-4.4.2.jar -g1 -fsource=1.5 >>>>> -ftarget=1.5 -fzip-dependency /tmp/ccTF9EKh.zip >>>>> Exception in thread "main" java.lang.ExceptionInInitializerError >>>>> at 0x1(Unknown Source) >>>>> at 0x3(Unknown Source) >>>>> at 0x5(Unknown Source) >>>>> at 0x5(Unknown Source) >>>>> at 0x5(Unknown Source) >>>>> at 0x5(Unknown Source) >>>>> at 0x5(Unknown Source) >>>>> at 0xffffffffffffffff(Unknown Source) >>>>> at 0x2(Unknown Source) >>>>> at 0xffffffffffffffff(Unknown Source) >>>>> at 0xffffffffffffffff(Unknown Source) >>>>> Caused by: java.lang.NullPointerException >>>>> at 0x1(Unknown Source) >>>>> at 0x5(Unknown Source) >>>>> at 0x4(Unknown Source) >>>>> ...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. Specifically 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. If 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: .s -> .o (linkable object code) >> ld: .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? > No. The testsuite can be run remotely. Dejagnu is quite flexible. If you have rcp/rsh working on your target, it is simple to have the testing infrastructure cross-build the tests and then copy them to the target to run. You can read the Dejagnu manual and search the archives of java@ for pointers about how to do this. David Daney > Thank you. >