* Re: NullPointerException throwed when running GCJ
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
2 siblings, 0 replies; 7+ messages in thread
From: majia gm @ 2010-12-29 8:34 UTC (permalink / raw)
To: David Daney; +Cc: gcc-help, Java List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NullPointerException throwed when running GCJ
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
2 siblings, 0 replies; 7+ messages in thread
From: Dr Andrew John Hughes @ 2010-12-29 14:40 UTC (permalink / raw)
To: majia gm; +Cc: David Daney, gcc-help, Java List
On 16:01 Wed 29 Dec , 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.
>
> 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 does source to bytecode compilation
jc1 does bytecode to native code compilation
gcj requires ecj to translate source code to bytecode. It was used to
replace the original gcj source code compiler with one that supported
the new Java 1.5 feature set. I presume you could avoid ecj if you only
ever compiled class files to native code, but I've never tried it. To
have a complete gcj installation, you do need ecj.
Note that ecj is written in Java and is compiled to native code during
the build of gcj, so it uses the same facilities of gcj as other Java
classes do to run.
You can use gcj -C to just do source to bytecode compilation and turn
a .java file into a .class file. You can also pass gcj jar and class
files and get it to return native code.
$ gcj -C Test.java
$ file Test.class
Test.class: compiled Java class data, version 49.0 (Java 1.5)
$ gcj -o test.o -c Test.class
$ file test.o
test.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
> If you could give me some hints, I would really appreciate.
>
> Thank you.
> Gmmajia
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NullPointerException throwed when running GCJ
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
2 siblings, 1 reply; 7+ messages in thread
From: David Daney @ 2010-12-29 17:01 UTC (permalink / raw)
To: majia gm; +Cc: gcc-help, Java List
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NullPointerException throwed when running GCJ
2010-12-29 17:01 ` David Daney
@ 2010-12-30 2:26 ` majia gm
2010-12-30 17:38 ` David Daney
0 siblings, 1 reply; 7+ messages in thread
From: majia gm @ 2010-12-30 2:26 UTC (permalink / raw)
To: David Daney; +Cc: gcc-help, Java List
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NullPointerException throwed when running GCJ
2010-12-30 2:26 ` majia gm
@ 2010-12-30 17:38 ` David Daney
0 siblings, 0 replies; 7+ messages in thread
From: David Daney @ 2010-12-30 17:38 UTC (permalink / raw)
To: majia gm; +Cc: gcc-help, Java List
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.
>
^ permalink raw reply [flat|nested] 7+ messages in thread