This is a copy of gnu classpath bug report #28570
(since I don't know wheather this is a JamVM or a
classpath bug)
-------------
This problem occurs on ARM platform (a Nokia 770;
Scratchbox 0.9.8 was used for
crosscompilation). It does not occur on a x86 platform.
When a float parameter is passed to a Java method from
within native code,
allways "0" is passed to Java instead of the correct
float value.
When double is used instead of float, the problem does
not occur.
This problem has been observed when using
"CallStatic<...>Method(...)" and
"Call<...>Method(...)" calls.
The problem could be reproduced with JamVM 1.4.1 and
1.4.3 (classpath 0.19).
The code below prints the following on a x86 platform
(correct output):
Received 100.0
Received 1234.0
Returned 100.0
The output on an ARM platform is:
Received 0.0
Received 0.0
Returned 100.0
--- Code to reproduce the problem ---
----- JAVA -----
public class FloatTest {
public static void main(String[] args){
System.loadLibrary("floatTest");
float myFloat=100.0f;
float returned=nativeMethod( myFloat );
System.out.println("Returned "+returned);
}
private static void printFloat(float f){
System.out.println("Received "+f);
}
private static native float nativeMethod(float f);
}
------- native code -------
#include <jni.h>
#include "FloatTest.h"
JNIEXPORT jfloat JNICALL
Java_FloatTest_nativeMethod(JNIEnv *env, jclass cls,
jfloat f){
env->CallStaticVoidMethod(cls,
env->GetStaticMethodID(cls,
"printFloat", "(F)V"), f);
env->CallStaticVoidMethod(cls,
env->GetStaticMethodID(cls,
"printFloat", "(F)V"), (float)1234.0);
return f;
}
Logged In: NO
The same is for passing longs. On big endian xscale...
Logged In: NO
Add passing longs:
This may be problem of unhandled wrong alignment access. Try:
echo 3 > /proc/cpuinfo/alignment