Re: NullPointerException throwed when running GCJ

[David Daney <ddaney@caviumnetworks.com>]

On 12/29/2010 06:26 PM, majia gm wrote:
> 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?
>

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.
>