harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Date Wed, 12 Apr 2006 15:35:42 GMT
Hi Archie,

On 4/12/06, Archie Cobbs <archie@dellroad.org> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


--
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message