Weldon Washburn wrote:
There's nothing unusual about JCHEVM's native code dispatch.
However, JCHEVM constructs dynamic function calls itself (instead
of using libffi like SableVM does). So if C calling conventions under
Cygwin (which are what?) are different than Linux, you could see
misalignment of parameters, etc.
hmmm.... this is starting to sound like classic ABI issues. I will
investigate and report back. Different tool chains take different
approaches to passing arguments. I noticed a comment in
arch_functions.c that says, "We use __attribute__ ((regparm(3))) which
places the first three arguments..." I gdb stepped through
_jc_dynamic_invoke() and noticed that it copies three slots off of the
machine stack and puts them in registers. I guess I need to compile
the native method with __attribute__ ((regparm(3))) ??
The regparm() stuff is only used for JCNI native dispatch, not
JNI dispatch. I.e., it's only used internally within JCHEVM itself.
So this should not affect handling of JNI native dispatch.
Not sure what you mean by name decoration and build options.
The problem is aligning the java classes with the native methods they
call. The goal is definitely zero mods to native-src directory. But
I suspect this will depend on ABI issues for the different platforms.
In specific, netBSD vs. Linux vs. Windows vs. Cygwin vs. Xen...
I still don't understand... the consistency of Java native method name
and parameter declarations with the C code that implements them (which
is specified exactly in the JNI specification and is the same everywhere)
seems like a completely different issue from whether the JVM and native
methods were compiled using the same ABI.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
