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

__________________________________________________________________________
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]

Reply via email to