harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Date Wed, 12 Apr 2006 14:04:25 GMT
Weldon Washburn wrote:
> 1)
> libtool was not behaving.  So, I gave up and used raw ld.
> 2)
> dlopen() refused to load the output of ld. Google turned up help pages
> that showed dlopen() only likes files ending in *.a
> 3)
> Once dlopen() was able to open the shared lib containing the native
> method, gdb was getting lost.  Googling the web again turned up a
> magic input arg to ld called "--enable-auto-image-base".  Apparently
> gdb internals are stepping on the same virtual addr as the newly
> loaded lib?? In any case, the  --enable.... worked around it.
> 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.

> 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.


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

View raw message