public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
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: Wed, 29 Dec 2010 08:34:00 -0000	[thread overview]
Message-ID: <AANLkTinuRjc+VxWi=b-Ucw+dx4EVtM-rv0ts+KzKpc7z@mail.gmail.com> (raw)
In-Reply-To: <AANLkTinnUGh42bhhhZ_AwPsdnMPyqzyLqQO_g4Pji3uY@mail.gmail.com>

2010/12/29 majia gm <gmmajia@gmail.com>:
> 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.
>
> 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.
>
> If you could give me some hints, I would really appreciate.
>
> Thank you.
> Gmmajia
>

Sorry, I make a mistake in the last massege.
The gcj on the target can compile the class file
HelloWorld.class into native executable file, but cannot compile the
source file HelloWorld.java.

  reply	other threads:[~2010-12-29  8:34 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 [this message]
2010-12-29 14:40     ` Dr Andrew John Hughes
2010-12-29 17:01     ` David Daney
2010-12-30  2:26       ` majia gm
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='AANLkTinuRjc+VxWi=b-Ucw+dx4EVtM-rv0ts+KzKpc7z@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).