Hi Archie, On 4/12/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: > Weldon Washburn wrote: > > 4) > > There was real difficulty lining up the native method's incoming > > arguments. Finally I declared the native method with input arguments > > (int a1, int a2, int a3, int a4). Then passed the character to be > > printed in all four arg slots. Surprise! The second arg of the C > > routine actually held the correct argument. So the native method was > > modified to print just a2. It works fine. > > > > Question for SableVM/JCHEVM guys: Did I miss the documentation on > > lining up native method args? Can you point me to the correct place > > to figure out how to do this? > > All of the above is completely mysterious to me and a good example > of why I avoid Windows at all costs. Sorry I can't be more help... > > 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))) ?? > > > Also, I modified files in Harmony Classlib's native-src directory. > > This might mean we need to add an additional level below > > enhanced/gnuclasspathadapter/. Something like > > enhanced/gnuclasspathadapter/native-src... Another issue is that > > different GNU Classpath JVMs may require different name decoration and > > different build options. Two ways of handling this are 1) add a > > subdirectory for each JVM that contains the code that is unique to the > > jvm and 2) use #ifdefs and make file options to handle the > > differences. > > I don't yet see why the gnuclasspath adapter can't be completely generic. > Doesn't (or shouldn't) the adapter consist only of Java classes? > > 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... > > -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] > > -- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
