From: majia gm <gmmajia@gmail.com>
To: David Daney <ddaney@caviumnetworks.com>
Cc: gcc-help@gcc.gnu.org, Java List <java@gcc.gnu.org>
Subject: Re: NullPointerException throwed when running GCJ
Date: Thu, 30 Dec 2010 02:26:00 -0000 [thread overview]
Message-ID: <AANLkTin-6GY0KBrvCqq2mjp3QWRjzbADDLYULGXmOw4j@mail.gmail.com> (raw)
In-Reply-To: <4D1B6955.9070001@caviumnetworks.com>
2010/12/30 David Daney <ddaney@caviumnetworks.com>:
> On 12/29/2010 12:01 AM, majia gm wrote:
>>
>> 2010/12/29 David Daney<ddaney@caviumnetworks.com>:
>>>
>>> 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?
Thank you.
next prev parent reply other threads:[~2010-12-30 2:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTikiHn2UOYNsQE8VcZo-8GgEmKdXDAAGVrOXRZJB@mail.gmail.com>
2010-12-28 17:36 ` David Daney
2010-12-29 8:01 ` majia gm
2010-12-29 8:34 ` majia gm
2010-12-29 14:40 ` Dr Andrew John Hughes
2010-12-29 17:01 ` David Daney
2010-12-30 2:26 ` majia gm [this message]
2010-12-30 17:38 ` David Daney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTin-6GY0KBrvCqq2mjp3QWRjzbADDLYULGXmOw4j@mail.gmail.com \
--to=gmmajia@gmail.com \
--cc=ddaney@caviumnetworks.com \
--cc=gcc-help@gcc.gnu.org \
--cc=java@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).