--- Comment #9 from hjl at lucon dot org 2006-01-18 19:34 ---
Looks at interpret.s
.Ldebug_line0:
.text
.Ltext0:
.section.ctors,"aw",@progbits
.align 8
.quad _GLOBAL__I__Jv_soleInterpreterEngine
#APP
.byte 0 # Yes, this really is necess
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-18 19:31 ---
Both prims.o and interpret.o are created from C++ code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-18 19:30 ---
Hmm:
interpret.o: file format elf64-x86-64
Contents of section .ctors:
0010 48c7c00f 000f 05 H
prims.o: file fo
--- Comment #6 from hjl at lucon dot org 2006-01-18 19:23 ---
It looks like gcc puts some junks in .ctors section:
[EMAIL PROTECTED] .libs]$ objdump -s -j .ctors libgcj.so.7
libgcj.so.7: file format elf64-x86-64
Contents of section .ctors:
190c000 0
--- Comment #5 from hjl at lucon dot org 2006-01-18 18:48 ---
I found this in my build log
creating gcj-dbtool ./gcj-dbtool -n classmap.db || touch classmap.db
creating gij /bin/sh: line 1: 17842 Segmentation fault ./gcj-dbtool -n
classmap.db
make[5]: Leaving directory
`/export/bui
--- Comment #4 from hjl at lucon dot org 2006-01-18 17:47 ---
I rebuilt crt*.o* with -fno-toplevel-reorder -fno-unit-at-a-time and
recreated lib*.so. I still have the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
--- Comment #3 from ian at airs dot com 2006-01-18 17:39 ---
Building a cross-compiler did not shed any light on the problem.
Can anybody provide more information about what is going wrong?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25840
--- Comment #2 from ian at airs dot com 2006-01-18 17:04 ---
I just reconfirmed that I don't see any problems running the libjava testsuite
on i686-pc-linux-gnu. And I don't have access to any x86_64 systems. So I
can't recreate this problem myself.
The backtrace suggests that there i
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Keywords||wrong-code
