[Bug java/16899] New: Gcj does not produce working executables for big endian ARMs

[Bug java/16899] New: Gcj does not produce working executables for big endian ARMs

[jari dot korva at iki dot fi]

HelloWorld application compiled with gcj segfaults on armv5b-softfloat-linux
architecture (i.e. XScale IXP 422).

gdb output:

Program received signal SIGSEGV, Segmentation fault.
0x0001de4c in _Jv_FindClass (name=0x2a6820, loader=0x0)
    at
/wrk/arm-linux/crosstool-0.28-rc31/build/armv5b-softfloat-linux/gcc-3.4.0-glibc-2.3.2/gcc-3.4.0/libjava/java/lang/natClassLoader.cc:507
507               klass = sys->loadClass (sname, false); 

strace output:

open("/lib/ld-linux.so.2", O_RDONLY)    = 3
read(3, "\177ELF\1\2\1a\0\0\0\0\0\0\0\0\0\3\0(\0\0\0\1\0\0\35\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=93428, ...}) = 0
brk(0x2d9000)                           = 0x2d9000
brk(0x2da000)                           = 0x2da000
old_mmap(NULL, 124772, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4012f000
mprotect(0x40145000, 34660, PROT_NONE)  = 0
old_mmap(0x40147000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x10000) = 0x40147000
old_mmap(0x4014d000, 1892, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014d000
close(3)                                = 0
mprotect(0x4012f000, 90112, PROT_READ|PROT_WRITE) = 0
mprotect(0x4012f000, 90112, PROT_READ|PROT_EXEC) = 0
mprotect(0x40011000, 1101824, PROT_READ|PROT_WRITE) = 0
mprotect(0x40011000, 1101824, PROT_READ|PROT_EXEC) = 0
mprotect(0x40000000, 36864, PROT_READ|PROT_WRITE) = 0
mprotect(0x40000000, 36864, PROT_READ|PROT_EXEC) = 0
brk(0)                                  = 0x2da000
brk(0x2da180)                           = 0x2da180
brk(0)                                  = 0x2da180
brk(0x2db000)                           = 0x2db000
open("/etc/passwd", O_RDONLY)           = 3
fcntl64(3, F_GETFD)                     = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=972, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4014e000
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 972
close(3)                                = 0
munmap(0x4014e000, 4096)                = 0
getcwd("/wrk/java-test", 250) = 26
open("/lib/", O_RDONLY)                 = 3
read(3, 0xbffff150, 1024)               = -1 EISDIR (Is a directory)
close(3)                                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(3, 0), ...}) = 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib/gconv/gconv-modules", O_RDONLY) = -1 ENOENT (No such file or
directory)
brk(0)                                  = 0x2db000
brk(0x2e3000)                           = 0x2e3000
brk(0)                                  = 0x2e3000
brk(0x2e4000)                           = 0x2e4000
brk(0)                                  = 0x2e4000
brk(0)                                  = 0x2e4000
brk(0x2f4000)                           = 0x2f4000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

The application was compiled with:

% armv5b-softfloat-linux-gcj -v
Reading specs from /cross/lib/gcc/armv5b-softfloat-linux/3.4.0/specs
Reading specs from
/cross/lib/gcc/armv5b-softfloat-linux/3.4.0/../../../../armv5b-softfloat-linux/lib/libgcj.spec
rename spec lib to liborig
Configured with:
/wrk/arm-linux/crosstool-0.28-rc31/build/armv5b-softfloat-linux/gcc-3.4.0-glibc-2.3.2/gcc-3.4.0/configure
--target=armv5b-softfloat-linux --host=i686-host_pc-linux-gnu
--prefix=/tmp/cross --with-float=soft --with-cpu=xscale
--enable-cxx-flags=-mcpu=xscale
--with-headers=/tmp/cross/armv5b-softfloat-linux/include
--with-local-prefix=/tmp/cross/armv5b-softfloat-linux --disable-nls
--enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c,c++,java --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 3.4.0

... and executed on a:

# uname -a
Linux 2.4.18_mvl30-ixdp425 #605 Thu Apr 15 17:36:30 CST 2004 armv5teb unknown

-- 
           Summary: Gcj does not produce working executables for big endian
                    ARMs
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jari dot korva at iki dot fi
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org
 GCC build triplet: i686-linux
  GCC host triplet: armv5b-softfloat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[jari dot korva at iki dot fi]

------- Additional Comments From jari dot korva at iki dot fi  2004-08-16 08:36 -------
By chance, I found out that by commenting out a few lines from
ClassLoader.getSystemClassLoader(), I'm able to produce working binaries for armv5b.

I didn't include a patch because this does not seem look like a real solution:

  public static ClassLoader getSystemClassLoader()
  {
    // Check if we may return the system classloader
//    SecurityManager sm = System.getSecurityManager();
//    if (sm != null)
      {
	Class c = VMSecurityManager.getClassContext()[1];
	ClassLoader cl = c.getClassLoader();
//	if (cl != null && cl != systemClassLoader)
//	  sm.checkPermission(new RuntimePermission("getClassLoader"));
      }

    return systemClassLoader;
  }

Does anyone who has more knowlegde about gcj internals have any idea what is the
real reason behind this? I also confirmed that the bug still exists in gcj 3.4.1.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|3.4.0                       |3.4.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2004-08-16 18:07 -------
That is strange. Unless your application code installed a security manager,
System.getSecurityManager() should always return null, thus the code you
commented out should never be executed anyway.

The two lines you didn't comment out are a no-op, they have no effect on the
return value.

Could you check to make sure that the System.getSecurityManager() is returning null?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[jari dot korva at iki dot fi]

------- Additional Comments From jari dot korva at iki dot fi  2004-08-17 08:06 -------
Yes, in normal case sm is null and those two lines are not executed. After that
there's a SIGSEGV in _Jv_FindClass because
java::lang::ClassLoader::getSystemClassLoader () returned NULL.

Is it possible that those method calls have some side-effects so that something
that was not otherwise initialized is now set up properly?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2004-08-17 15:43 -------
It is ok for ClassLoader.getSystemClassLoader() to return null - Sun's
implementation uses null here to represent the "bootstrap" class loader. It is
wrong for _Jv_FindClass to assume that getSystemClassLoader won't return null.
_Jv_FindClass needs a different way to get the bootstrap class loader.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2004-08-17 15:53 -------
Created an attachment (id=6949)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6949&action=view)
Proposed patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2004-08-17 15:55 -------
I suspect that ClassLoader was not initialized prior to _Jv_InitClass being
called. CNI does not automatically ensure that Java classes are initialized.
Could you try this patch?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-18 05:27 -------
I think this can be confirmed now.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-18 05:27:35
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[jari dot korva at iki dot fi]

------- Additional Comments From jari dot korva at iki dot fi  2004-08-18 09:57 -------
The patch did not apply cleanly to 3.4.1, but I made similar changes by hand. It
didn't fix the problem, i.e. sys remains NULL and the app segfaults.

I would try it on cvs version too, but gcc still seems to need patches for big
endian arm and I haven't had time to play with those.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug java/16899] Gcj does not produce working executables for big endian ARMs

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2004-08-18 15:15 -------
Can you provide a backtrace of when the SIGSEGV occurs? It might be that
_Jv_FindClass is being entered from inside the static initializer for
java.lang.ClassLoader, thus the systemClassLoader value hasn't been set yet.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug libgcj/16899] Gcj does not produce working executables for big endian ARMs

[jari dot korva at iki dot fi]

------- Additional Comments From jari dot korva at iki dot fi  2004-08-19 10:20 -------
Sorry, should have taken this earlier, I guess:

#0  0x0001de60 in _Jv_FindClass (name=null, loader=null) at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/natClassLoader.cc:515
#1  0x0001d48c in java::lang::Class::forName (className=@2a24f8, initialize=1,
loader=null) at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/natClass.cc:81
#2  0x0001d604 in java::lang::Class::forName (className=@2a24f8) at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/natClass.cc:113
#3  0x00067ac4 in gnu.gcj.convert.UnicodeToBytes.getDefaultEncoder() () at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/gnu/gcj/convert/UnicodeToBytes.java:49
#4  0x0003ac5c in java.io.PrintStream.PrintStream(java.io.OutputStream, boolean)
(this=@2b9b40, out=@2a7820, auto_flush=true) at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/io/PrintStream.java:118
#5  0x00031524 in java.lang.System.<clinit>() () at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/System.java:146
#6  0x0001d034 in java::lang::Class::initializeClass (this=@1d440c) at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/natClass.cc:808
#7  0x0001d6fc in _Jv_InitClass (klass=null) at Class.h:279
#8  0x00031878 in java.lang.System.getProperty(java.lang.String) (key=@2a7f00)
at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/System.java:405
#9  0x00034b44 in java.lang.VMClassLoader.getSystemClassLoader() () at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/VMClassLoader.java:280
#10 0x00028898 in java.lang.ClassLoader.<clinit>() () at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/ClassLoader.java:156
#11 0x0001d034 in java::lang::Class::initializeClass (this=@1cf024) at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/natClass.cc:808
#12 0x000097b4 in _Jv_CreateJavaVM () at Class.h:279
#13 0x00009938 in _Jv_RunMain (klass=@1cc43c, name=null, argc=1, argv=@bffffdf4,
is_jar=false) at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/prims.cc:988
#14 0x00009b10 in JvRunMain (klass=null, argc=-1073742888, argv=@22b898) at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/prims.cc:1026
#15 0x000081f4 in main ()

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug libgcj/16899] Gcj does not produce working executables for big endian ARMs

[mckinlay at redhat dot com]

------- Additional Comments From mckinlay at redhat dot com  2004-08-19 14:42 -------
Thanks. Here's the problem:

#9  0x00034b44 in java.lang.VMClassLoader.getSystemClassLoader() () at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/VMClassLoader.java:280
#10 0x00028898 in java.lang.ClassLoader.<clinit>() () at
/crosstool-0.28-rc32/build/armv5b-softfloat-linux/gcc-3.4.1-glibc-2.3.2/gcc-3.4.1/libjava/java/lang/ClassLoader.java:156

ie the class initializer for ClassLoader, and specifically the
getSystemClassLoader() call, is eventually dependent on itself. 

We need to figure out a way to break the dependency chain. First step is
probably to figure out why this is happening on your target, but not others.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug libgcj/16899] Gcj does not produce working executables for big endian ARMs

[jari dot korva at iki dot fi]

------- Additional Comments From jari dot korva at iki dot fi  2004-08-20 07:30 -------
Thanks! This starts to look like a duplicate of...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13708

I tried the associated workaround
(http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03355.html) and it seems to fix
the problem.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899

[Bug libgcj/16899] Gcj does not produce working executables for big endian ARMs

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-20 07:35 -------
Oh, so we don't support shared libraries on ARM Linux ok so then it is a dup of that 
bug then.

*** This bug has been marked as a duplicate of 13708 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899