Compiling specific Java file of the Red Hat GCJ/rhug tree: arm-linux-gcj -fCLASSPATH=upstream/src:./upstream/src -O2 -save-temps -dp -v --encoding=8859_1 -fassume-compiled -O2 -c upstream/src/org/apache/xerces/validators/dtd/DTDGrammar.java -MT upstream/src/org/apache/xerces/validators/dtd/lib_org_apache_xerces_la-DTDGrammar.lo -MD -MP -MF upstream/src/org/apache/xerces/validators/dtd/.deps/lib_org_apache_xerces_la-DTDGrammar.TPlo -fPIC -o upstream/src/org/apache/xerces/validators/dtd/.libs/lib_org_apache_xerces_la-DTDGrammar.lo Using arm-linux-gcc cross-compiler, GCJ generates object-files with undefined symbol references. For example: /home/jsantala/rhug-clean/xerces/.libs/lib-org-apache-xerces.so: undefined reference to `.L153' /home/jsantala/rhug-clean/xerces/.libs/lib-org-apache-xerces.so: undefined reference to `.L156' nm output of affected source module: U .L153 U .L156 000000d8 d _CD_org_apache_xerces_validators_dtd_DTDGrammar ... From assembler source: ... .L164: bl _Jv_ThrowBadArrayIndex(PLT) @ 855 *call_value_symbol/1 [length = 4] .align 2 .L155: b .L156 b .L156 b .L156 b .L156 b .L156 b .L156 b .L153 .L166: ldr r3, .L169+20 @ 1003 pic_load_addr_arm [length = 4] ... If compiler is ran with -fverbose-asm, it crashes with segmentation fault ICE: gcc version 3.1 20020122 (experimental) GNU Java version 3.1 20020122 (experimental) (arm-linux) compiled by GNU C version 3.0.3. Class path starts here: upstream/src/ ./upstream/src/ ./ /skiff/local/share/libgcj.jar/ (system) (zip) upstream/src/org/apache/xerces/validators/dtd/DTDGrammar.java:174: internal error: Segmentation fault (gdb) where #0 get_mem_expr_from_op (op=0x0, paddressp=0xbfffef98) at ../../gcc/gcc/final.c:3016 #1 0x08127f09 in output_asm_operand_names (operands=0xbffff1b0, oporder=0xbffff050, nops=1) at ../../gcc/gcc/final.c:3061 #2 0x08128053 in output_asm_insn ( template=0xbffff110 "ldm%?%d0fd\t%|sp!, {%|r4, %|r5, %|r6, %|r7, %|r8, %|r9, %|sl, %|pc}", operands=0xbffff1b0) at ../../gcc/gcc/final.c:3289 #3 0x0822130b in output_return_instruction (operand=0x0, really_return=1, reverse=0) at ../../gcc/gcc/config/arm/arm.c:7353 #4 0x0816eeed in output_259 (operands=0x83623c0, insn=0x4039a640) at insn-output.c:1325 #5 0x08126cc4 in get_insn_template (code=259, insn=0x4039a640) at ../../gcc/gcc/final.c:1809 #6 0x0812701c in final_scan_insn (insn=0x4039a640, file=0x8385d88, optimize=2, prescan=0, nopeepholes=0) at ../../gcc/gcc/final.c:2591 #7 0x08126c0a in final (first=0x40396580, file=0x8385d88, optimize=2, prescan=0) at ../../gcc/gcc/final.c:1787 #8 0x081f78b4 in rest_of_compilation (decl=0x401c1d98) at ../../gcc/gcc/toplev.c:3464 #9 0x08063d94 in source_end_java_method () at ../../gcc/gcc/java/parse.y:7457 #10 0x08065ab1 in java_expand_method_bodies (class=0x401ba6cc) at ../../gcc/gcc/java/parse.y:8133 ... File DTDGramma.java from Apache-XML Xerces-Java project attached. Linking passes with -O0, but not with -O1 or -O2 Release: 3.1 20020122 (experimental) Environment: Using Red Hat 7.1, with GCC compiled as arm-linux cross-compiler. How-To-Repeat: arm-linux-gcj -fCLASSPATH=upstream/src:./upstream/src -O2 -save-temps -dp -v --encoding=8859_1 -fassume-compiled -O2 -c upstream/src/org/apache/xerces/validators/dtd/DTDGrammar.java -MT upstream/src/org/apache/xerces/validators/dtd/lib_org_apache_xerces_la-DTDGrammar.lo -MD -MP -MF upstream/src/org/apache/xerces/validators/dtd/.deps/lib_org_apache_xerces_la-DTDGrammar.TPlo -fPIC -o upstream/src/org/apache/xerces/validators/dtd/.libs/lib_org_apache_xerces_la-DTDGrammar.lo Have not tried to minimize test-case yet.
State-Changed-From-To: open->feedback State-Changed-Why: OK, first-off I'm not a java programmer. However, I've tried running your test-case and I get a load of errors that suggest that the testcase is incomplete. Please provide the missing information and/or instructions for how I can reproduce this in isolation. linux16:tmp [1093] $ ~/gnu/egcs/arm-elf/gcc/gcj -B ~/gnu/egcs/arm-elf/arm-el f/libjava/ -B ~/gnu/egcs/arm-elf/gcc/ -fCLASSPATH=./:/home/rearnsha/gnu/egcs/arm -elf/arm-elf/libjava/ -O2 -save-temps -dp -v --encoding=8859_1 -fassume-compiled -O2 -c DTDGrammar.java -MT lib_org_apache_xerces_la-DTDGrammar.lo -MD -MP -MF l ib_org_apache_xerces_la-DTDGrammar.TPlo -fPIC -o lib_org_apache_xerces_la-DTD Grammar.lo Reading specs from /home/rearnsha/gnu/egcs/arm-elf/gcc/specs Reading specs from /home/rearnsha/gnu/egcs/arm-elf/arm-elf/libjava/libgcj.spec rename spec lib to liborig Configured with: /home/rearnsha/gnusrc/egcs-cross/configure --prefix=/home/rearn sha/gnu/egcs//arm-elf-install --disable-checking --target=arm-elf --with-headers =/home/rearnsha/gnusrc/egcs-cross/newlib/libc/include Thread model: single gcc version 3.2 20020322 (experimental) /home/rearnsha/gnu/egcs/arm-elf/gcc/jc1 DTDGrammar.java -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase D TDGrammar.java -dp -O2 -O2 -version -fCLASSPATH=./:/home/rearnsha/gnu/egcs/arm-e lf/arm-elf/libjava/ -fencoding=8859_1 -fassume-compiled -fPIC -MD -MT lib_org_ap ache_xerces_la-DTDGrammar.lo -MF lib_org_apache_xerces_la-DTDGrammar.TPlo -o DTD Grammar.s GNU Java version 3.2 20020322 (experimental) (arm-elf) compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.1 2.96-81). Class path starts here: ./ /home/rearnsha/gnu/egcs/arm-elf/arm-elf/libjava/ /home/rearnsha/gnu/egcs//arm-elf-install/share/libgcj.jar/ (system) (zip) DTDGrammar.java:70: Class or interface `org.apache.xerces.validators.schema.XUti l' not found in import. import org.apache.xerces.validators.schema.XUtil; ^ DTDGrammar.java:91: Superclass `Grammar' of class `org.apache.xerces.validators. dtd.DTDGrammar' not found. extends Grammar ^ DTDGrammar.java:92: Superinterface `XMLDTDScanner.EventHandler' of class `org.ap ache.xerces.validators.dtd.DTDGrammar' not found.
From: Tom Tromey <tromey@redhat.com> To: rearnsha@gcc.gnu.org Cc: gcc-bugs@gcc.gnu.org.jsantala@tml.hut.fi, gcc-gnats@gcc.gnu.org Subject: Re: java/5487: arm-linux-gcj cross-compiler generates bad assembler-code Date: 23 Mar 2002 21:05:55 -0700 Richard> OK, first-off I'm not a java programmer. However, I've tried Richard> running your test-case and I get a load of errors that Richard> suggest that the testcase is incomplete. Please provide the Richard> missing information and/or instructions for how I can Richard> reproduce this in isolation. In the PR he says that the code comes from rhug. You can find rhug here: http://sources.redhat.com/rhug/ It's all available via anonymous cvs. I can build rhug fine on x86. Last time I tried was a couple weeks ago. Tom
From: Richard Earnshaw <rearnsha@arm.com> To: Tom Tromey <tromey@redhat.com> Cc: nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org, Richard.Earnshaw@arm.com Subject: Re: java/5487: arm-linux-gcj cross-compiler generates bad assembler-code Date: Mon, 25 Mar 2002 11:39:29 +0000 tromey@redhat.com said: > In the PR he says that the code comes from rhug. You can find rhug > here: > http://sources.redhat.com/rhug/ > It's all available via anonymous cvs. However, http://gcc.gnu.org/bugs.html says: What we do not want ... The location (URL) of the package that failed to build (we won't download it, anyway, since you've already given us what we need to duplicate the bug, haven't you? :-)
From: Tom Tromey <tromey@redhat.com> To: Richard.Earnshaw@arm.com Cc: gcc-gnats@gcc.gnu.org Subject: Re: java/5487: arm-linux-gcj cross-compiler generates bad assembler-code Date: 25 Mar 2002 14:04:48 -0700 >>>>> "Richard" == Richard Earnshaw <rearnsha@arm.com> writes: Richard> What we do not want Richard> ... Richard> The location (URL) of the package that failed to build (we won't Richard> download it, anyway, since you've already given us what we need to Richard> duplicate the bug, haven't you? :-) Yeah. Java is a little different from C or C++. You can't send a `.i' file that encapsulates everything you need for the bug. Still, I agree that downloading something is a pain and it is much, much more convenient to have a small archive that demonstrates the bug. OTOH, rhug is sort of a special case. It is one of the important gcj applications that we want to build out of the box. Tom
From: Richard Earnshaw <rearnsha@arm.com> To: tromey@redhat.com Cc: Richard.Earnshaw@arm.com, gcc-gnats@gcc.gnu.org Subject: Re: java/5487: arm-linux-gcj cross-compiler generates bad assembler-code Date: Tue, 26 Mar 2002 13:41:34 +0000 tromey@redhat.com said: > OTOH, rhug is sort of a special case. It is one of the important gcj > applications that we want to build out of the box. Except, of course, that it doesn't; particularly for a cross system. ~/gnusrc/rhug/configure --target=arm-elf --prefix=/home/rearnsha/gnu/egcs/a rm-elf-install ... checking for gcj... no checking for gcjh... no configure: error: no acceptable gcjh found in $PATH cam-linux16:rhug [1006] $ arm-elf-gc arm-elf-gcc arm-elf-gcj arm-elf-gcov arm-elf-gccbug arm-elf-gcjh It should be looking for the cross compiler, not a native one in a cross build. I'm sorry, I just don't have the time to spend tracking down this problem; there's just too many prerequisites that are in the way. If someone can produce an isolated test-case, which doesn't require pre-installing a load of other packages, then I'll look into it further. R.
State-Changed-From-To: feedback->closed State-Changed-Why: Testcase hasn't been cut down to be usable; been in feedback for 9 months.
I've been able to reproducte the same exact issue in arm-linux-gcc-4.0.1 which I build from source by the following process: ===code============================================================ ../configure --target=arm-linux --with-gnu-as --with-gnu-ld --enable-multilib --enable-languages=c,c++,java --disable-nls --nfp --with-cpu-xscale --with-softfloat-support=internal make make install =================================================================== I then compiled a HelloWorld.java App using the newly created gcj as follows: ===code============================================================ /usr/local/bin/arm-linux-gcj -static HelloWorld.java --main=HelloWorldApp -g -o HelloWorld.exe =================================================================== Compilation seemed to go fine without errors. HelloWorld.exe appears to be a correctly formated binary according to "file": ===code============================================================ HelloWorld.exe: ELF 32-bit LSB executable, Advanced RISC Machines ARM, version 1, statically linked, not stripped =================================================================== The binary was then downloaded to a PXA-255 based system running armcore-2.6.7 linux. Upon execution the executable reports the segmentation fault: ===code============================================================ [root@ARMCore test]$ ./HelloWorld.exe Segmentation fault =================================================================== I'd like to see this bug reopened.
I now have a stacktrace from someone on this issue from gdb: They used the following configuration parameters to build arm-linux-gcc cross compilers: The following was tested with gcc-3.4.3 and gcc-4.0.1 sources with the same issue. ===code================================================================== $ arm-linux-gcj -v Configured with: ../gcc-3.4.3/configure --target=arm-linux --prefix=/group/teaching/iar/armcore-gx/toolchain --enable-languages=c,c++,objc,java --disable-nls --nfp --with-cpu=xscale --with-softfloat-support=internal Thread model: posix gcc version 3.4.3 ========================================================================= Here is the stacktrace: ===code================================================================== $ arm-linux-gcj -ggdb --main=HelloWorld -o hello HelloWorld.java running ./hello causes segfault $ gdb hello Program received signal SIGSEGV, Segmentation fault. GC_push_all_eager (bottom=0x0, top=0x390a8 "") at ../../../gcc-3.4.3/boehm-gc/mark.c:1468 1468 ../../../gcc-3.4.3/boehm-gc/mark.c: No such file or directory. in ../../../gcc-3.4.3/boehm-gc/mark.c (gdb) bt #0 GC_push_all_eager (bottom=0x0, top=0x390a8 "") at ../../../gcc-3.4.3/boehm-gc/mark.c:1468 #1 0x40637660 in GC_push_all_stacks () at ../../../gcc-3.4.3/boehm-gc/pthread_stop_world.c:232 #2 0x40632194 in GC_push_roots (all=1, cold_gc_frame=0xbefffaf4 "") at ../../../gcc-3.4.3/boehm-gc/mark_rts.c:643 #3 0x406316a4 in GC_mark_some (cold_gc_frame=0xbefffaf4 "") at ../../../gcc-3.4.3/boehm-gc/mark.c:326 #4 0x406289e8 in GC_stopped_mark (stop_func=0x40628640 <GC_never_stop_func>) at ../../../gcc-3.4.3/boehm-gc/alloc.c:517 #5 0x40629488 in GC_try_to_collect_inner (stop_func=0x40628640 <GC_never_stop_func>) at ../../../gcc-3.4.3/boehm-gc/alloc.c:364 #6 0x40632c38 in GC_init_inner () at ../../../gcc-3.4.3/boehm-gc/misc.c:758 #7 0x40632f00 in GC_init () at ../../../gcc-3.4.3/boehm-gc/misc.c:477 #8 0x4062d04c in GC_init_gcj_malloc (mp_index=0, mp=0x404337b8) at ../../../gcc-3.4.3/boehm-gc/gcj_mlc.c:60 #9 0x4043449c in _Jv_InitGC () at ../../../gcc-3.4.3/libjava/boehm.cc:526 #10 0x404367c4 in _Jv_CreateJavaVM () at ../../../gcc-3.4.3/libjava/prims.cc:907 #11 0x40436ca4 in _Jv_RunMain (klass=0x1107c, name=0x0, argc=1, argv=0xbefffdb4, is_jar=false) at ../../../gcc-3.4.3/libjava/prims.cc:992 #12 0x40436ec4 in JvRunMain (klass=0x0, argc=-1090519712, argv=0x0) at ../../../gcc-3.4.3/libjava/prims.cc:1030 #13 0x00008b04 in main (argc=1, argv=0xbefffdb4) at /tmp/cccmH5zI.i:11 =========================================================================
Subject: Re: arm-linux-gcj cross-compiler generates bad assembler-code On Wed, 2005-08-31 at 21:18, ngmlinux at gmail dot com wrote: > (gdb) bt > #0 GC_push_all_eager (bottom=0x0, top=0x390a8 "") at > ../../../gcc-3.4.3/boehm-gc/mark.c:1468 Which shows that your crash is in the garbage collector, and therefore nothing to do with this old bug report.
Subject: Re: arm-linux-gcj cross-compiler generates bad assembler-code > > (gdb) bt > > #0 GC_push_all_eager (bottom=0x0, top=0x390a8 "") at > > ../../../gcc-3.4.3/boehm-gc/mark.c:1468 > > Which shows that your crash is in the garbage collector, and therefore > nothing to do with this old bug report. Ok, I guess that verifies I did the right thing by filing a new one. Thanks. -Nathan