gcj on debian-arm host?
Guys:
Is anyone using gcj and family to produce a native executable (java
source) for an arm target?
I can use gcj on my debian PC just fine. On a debian-arm platform,
however, the very same source code compiled through the same version of
gcj segfaults.
After some poking around with gdb, it looks like it's in the heap/gc
setup that the segfault occurs. I can post more detailed information if
desired. I just want to know if I'm the first person to see this or
not, and if so, if anyone has any ideas as to what's going on before I
dive into it...
sh-3.00# cat HelloWorld.java
public class HelloWorld {
public static void main (String[] args) {
System.out.println("Hello, world!\n");
}
}
sh-3.00# gcj --version
gcj (GCC) 3.3.5 (Debian 1:3.3.5-13)
sh-3.00# gcj --main=HelloWorld -o HelloWorld HelloWorld.java
sh-3.00# ./HelloWorld
Segmentation fault
sh-3.00# file HelloWorld
HelloWorld: ELF 32-bit LSB executable, ARM, version 1 (ARM), for
GNU/Linux 2.2.0
, dynamically linked (uses shared libs), not stripped
sh-3.00# ldd HelloWorld
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4001d000)
libgcj.so.4 => /usr/lib/libgcj.so.4 (0x4002e000)
libm.so.6 => /lib/libm.so.6 (0x40716000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40790000)
libz.so.1 => /usr/lib/libz.so.1 (0x407e8000)
libdl.so.2 => /lib/libdl.so.2 (0x40802000)
libc.so.6 => /lib/libc.so.6 (0x4080c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
sh-3.00# strace ./HelloWorld
...
open("/proc/stat", O_RDONLY) = 3
read(3, "cpu 2523 0 4642 56570 140 233 7"..., 4096) = 481
close(3) = 0
brk(0) = 0x32000
brk(0) = 0x32000
brk(0x42000) = 0x42000
brk(0) = 0x42000
brk(0) = 0x42000
brk(0x52000) = 0x52000
brk(0) = 0x52000
brk(0) = 0x52000
brk(0x62000) = 0x62000
getpid() = 1786
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
b.g.
--
Bill Gatliff
bgat@billgatliff.com
Q: What lies on the bottom of the ocean and twitches?
A: A nervous wreck.
Reply to: