Skip to main content

byte swap problem

12 replies [Last post]
bzhou
Offline
Joined: 2003-08-15

$ uname -a
Linux hostname 2.4.22-xfs #1 Sun Jun 12 21:17:17 PDT 2005 armv5b GNU/Linux

$ Foundation_Profile-phoneme_advanced_mr2_b18-linux_arm_generic-bin-rev5826/bin/cvm -version
Porudtc :hpnoMe EdAavcnde( hpnome_edaavcndem_2rb-81)
Profile: oFnuaditnoP orifelS epicifacitno 1.1
JVM: VCM hpnome_edaavcndem_2rb-81 (imex dome)d
java.lang.ClassNotFoundException: sun.net.www.protocol.jar.aHdnerl
at java.lang.ClassLoader.loadBootstrapClass(Unknown Source)
at java.lang.Class.forName0(Native Methdo)
at java.lang.Class.forNameU(knonnwS uoc)re
at sun.misc.Launcher$Factory.createURLStreamHandler(Unknown Source)
at sun.misc.URLClassPath.(Unknown Source)
at java.net.URLClassLoader.(Unknown Sourc)e
at sun.misc.Launcher$ExtClassLoader.itU(knonnwS uoc)re
at sun.misc.Launcher$2.runU(knonnwS uoc)re
at java.security.AccessController.odrPviligedeU(knonnwS uoc)re
at java.security.AccessController.odrPviligedeU(knonnwS uoc)re
at sun.misc.Launcher$ExtClassLoader.egEttxlCsaLsaoedr(Unknown Sourc)e
at sun.misc.Launcher.(Unknown Source)
at sun.misc.Launcher$1.runU(knonnwS uoc)re
at java.security.AccessController.odrPviligedeU(knonnwS uoc)re
at java.security.AccessController.odrPviligedeU(knonnwS uoc)re
at sun.misc.Launcher.(Unknown Sourc)e
at java.lang.Class.runStaticInitializersU(knonnwS uocr)e
at java.lang.ClassLoader.initSystemClassLoaderU(knonnwS uoc)re
at java.lang.ClassLoader.getSystemClassLoader(Unknown Sourc)e
java.lang.InternalError: oclu don toldaj rassey trmtpcolohon lared
at sun.misc.Launcher$Factory.createURLStreamHandler(Unknown Source)
at sun.misc.URLClassPath.(Unknown Source)
at java.net.URLClassLoader.(Unknown Sourc)e
at sun.misc.Launcher$ExtClassLoader.itU(knonnwS uoc)re
at sun.misc.Launcher$2.runU(knonnwS uoc)re
at java.security.AccessController.odrPviligedeU(knonnwS uoc)re
at java.security.AccessController.odrPviligedeU(knonnwS uoc)re
at sun.misc.Launcher$ExtClassLoader.egEttxlCsaLsaoedr(Unknown Sourc)e
at sun.misc.Launcher.(Unknown Source)
at sun.misc.Launcher$1.runU(knonnwS uoc)re
at java.security.AccessController.odrPviligedeU(knonnwS uoc)re
at java.security.AccessController.odrPviligedeU(knonnwS uoc)re
at sun.misc.Launcher.(Unknown Sourc)e
at java.lang.Class.runStaticInitializersU(knonnwS uocr)e
at java.lang.ClassLoader.initSystemClassLoaderU(knonnwS uoc)re
at java.lang.ClassLoader.getSystemClassLoader(Unknown Sourc)e

This is on a big-endian IXP420 nslu2, with gcc-3.3.5-glibc-2.2.5 cross compiler running on x86 linux machine. I had to use CVM_FORCE_HARD_FLOAT=true USE_AAPCS=false to prevent other problems. But this is as far as I got.

Looks as if the byte-order is wrong in some places.

Any idea? Thanks in advance.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cjplummer
Offline
Joined: 2006-10-16

A fix was just commited for the big endian bugs in the arm memove_cpu.S. However, we don't have a big endian ARM device to test it out on. If you try it out and it works for you, please let us know.

thanks,

Chris

bzhou
Offline
Joined: 2003-08-15

With b34, phoneme advanced passes regression test on unslung (linux 2.4 glibc), slugosbe (linux 2.6 glibc), and openwrt-ixp4xx (linux 2.6 uclibc, reported by some other user). All are armeb firmware for nslu2.

Thanks,

-Brian Zhou

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> With b34, phoneme advanced passes regression test on unslung (linux 2.4 glibc), slugosbe (linux 2.6 glibc), and openwrt-ixp4xx (linux 2.6 uclibc, reported by some other user). All are armeb firmware for nslu2.
>
>

Thanks, Brian! Good info to know.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

bzhou
Offline
Joined: 2003-08-15

Mark my question as been answered.

mlam
Offline
Joined: 2006-10-13

Now that Chris pointed it out, it looks like your endianness problem is showing up in the C strings. Maybe there's a mismatch between your gcc ompiler and your target device. Can you do a compile a C HelloWorld program and see what the results look like?

bzhou
Offline
Joined: 2003-08-15

I've been using the same cross toolchain for a lot of non-trivial programs (perl, python, jamvm). So I'm pretty sure the gcc compiler and target device matches.

cjplummer
Offline
Joined: 2006-10-16

Big Endian on ARM is very rare, and the support for it in CDC was added without having ever tested it (because we didn't have a device to test it on).

This does look like an endianness problem, but I've never seen a CDC endianness bug manifest itself like this. The following two lines are interesting:

Porudtc :hpnoMe EdAavcnde( hpnome_edaavcndem_2rb-81)
Profile: oFnuaditnoP orifelS epicifacitno 1.1

Both "Product" and "Profile" are handled in almost the exact same way Version.java, but only one is messed up. It's almost like there are multiple transformations of the strings, and in the endianness world, two wrongs do make a right. Actually an even number of wrongs make a right.

The handling of "Unknown Source" in the backtrace is also inconsistent:

at sun.misc.URLClassPath.(Unknown Source)
at java.net.URLClassLoader.(Unknown Sourc)e
at sun.misc.Launcher$ExtClassLoader.itU(knonnwS uoc)re

It's pretty clear that there is a problem with endianness in the string handling. I'm not sure if the problem is with C strings or Java strings.

You should start by building with CVM_JIT=false just to eliminate the JIT as the source of the endianness problems (The JIT is far more susceptible to endianness bugs than the interpreter). Let me know if there are still problems with just the interpreter, and I'll try to come up with a next step for debugging it.

Chris

bzhou
Offline
Joined: 2003-08-15

Turning JIT off does not help, same output.

The nslu2 device I'm using is actually available off-the-shelf for about $80 - $90. With either unslung or slugosbe firmware, it's running Big Endian on ARM.

I can also try testing my debian nslu2 with debian's cross compiler, debian nslu2 runs in little endian. Will post the result here later.

To build toolchain for unslung, see http://www.nslu2-linux.org/wiki/Optware/AddAPackageToOptware;
To build toolchain for slugosbe, see
http://www.nslu2-linux.org/wiki/Development/MasterMakefile

Message was edited by: bzhou

cjplummer
Offline
Joined: 2006-10-16

Make sure your compiler #defines__ARMEB__. The linux-arm endianness_arch.h depends on it for big endian platforms.

Chris

bzhou
Offline
Joined: 2003-08-15

$ cat endian.c
#include

int main() {
#ifdef __ARMEB__
printf("big endian\n");
#else
printf("little endian\n");
#endif
return 0;
}

$ toolchain/armv5b-softfloat-linux/gcc-3.3.5-glibc-2.2.5/bin/armv5b-softfloat-linux-gcc -E endian.c | grep printf.*endian
printf("big endian\n");

cjplummer
Offline
Joined: 2006-10-16

In the linux-arm memory_arch.h, put a #if 0 around everything except for the #include of malloc.h, and see if that fixes the problem.

Chris

bzhou
Offline
Joined: 2003-08-15

Thanks Chris, that did it.

Foundation_Profile-phoneme_advanced_mr2_b18-linux_arm_generic-bin-rev5826$ ./bin/cvm -version
Product: phoneME Advanced (phoneme_advanced_mr2-b18)
Profile: Foundation Profile Specification 1.1
JVM: CVM phoneme_advanced_mr2-b18 (mixed mode)

...

*CONGRATULATIONS: test Test completed with 411 tests passed and 0 failures