Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
No. The IBM VME is not Apache licensed. To quote the download site: The IBM Development Package for Apache Harmony is complementary to, but not part of, the Apache Harmony Project. Read the license. Regards, -Mark. On 4/13/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > > 1) Copy the luni-kernel and security-kernel stubs and add > > > > implementation rather than doing it in place. The stubs are just for > > > > compilation we shouldn't add anything VM (or VM adapter) specific to > > > > them. > > > > > > hmm not sure what you are suggesting. The stubs allow the build > > > to finish properly but the resultant binary won't run on any JVM > > > because the stubs are hollow. > > > > Exactly! I'm saying we should leave them like that. > > I agree with you. This is good. Have you thought about copying IBM > VME makefiles and modifying them for the purpose? I am assuming these > makefiles are Apache licensed. > > > > > We should copy the hollow stubs to a classpathadapter project tree and > > modify those rather than modifying the copies in the classlib project. > > > > Aside: Since classlib is just compiling against these stub, it doesn't > > really matter if we modify them to add classpath adapter specific > > implementation. But I think it might be confusing to others coming to > > implement these kernel classes for a different VM. So we should keep > > them hollow and not make the classpath adapter "special". > > > > Then when we want to use the adapter, we overwrite the hollow stubs in > > the deploy directory. As I said: > > > > > > I think we should be looking to create something, that when > > > > combined with JCHEVM, can be dropped in to the deploy tree in the > > > > same way that the current IBM VME is dropped in. > > > > > HTH, > > Mark. > > > > -- > > Mark Hindess <[EMAIL PROTECTED]> > > IBM Java Technology Centre, UK. > > > > - > > 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] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > 1) Copy the luni-kernel and security-kernel stubs and add > > > implementation rather than doing it in place. The stubs are just for > > > compilation we shouldn't add anything VM (or VM adapter) specific to > > > them. > > > > hmm not sure what you are suggesting. The stubs allow the build > > to finish properly but the resultant binary won't run on any JVM > > because the stubs are hollow. > > Exactly! I'm saying we should leave them like that. I agree with you. This is good. Have you thought about copying IBM VME makefiles and modifying them for the purpose? I am assuming these makefiles are Apache licensed. > > We should copy the hollow stubs to a classpathadapter project tree and > modify those rather than modifying the copies in the classlib project. > > Aside: Since classlib is just compiling against these stub, it doesn't > really matter if we modify them to add classpath adapter specific > implementation. But I think it might be confusing to others coming to > implement these kernel classes for a different VM. So we should keep > them hollow and not make the classpath adapter "special". > > Then when we want to use the adapter, we overwrite the hollow stubs in > the deploy directory. As I said: > > > > I think we should be looking to create something, that when > > > combined with JCHEVM, can be dropped in to the deploy tree in the > > > same way that the current IBM VME is dropped in. > > HTH, > Mark. > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > 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]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > 1) Copy the luni-kernel and security-kernel stubs and add > > implementation rather than doing it in place. The stubs are just for > > compilation we shouldn't add anything VM (or VM adapter) specific to > > them. > > hmm not sure what you are suggesting. The stubs allow the build > to finish properly but the resultant binary won't run on any JVM > because the stubs are hollow. Exactly! I'm saying we should leave them like that. We should copy the hollow stubs to a classpathadapter project tree and modify those rather than modifying the copies in the classlib project. Aside: Since classlib is just compiling against these stub, it doesn't really matter if we modify them to add classpath adapter specific implementation. But I think it might be confusing to others coming to implement these kernel classes for a different VM. So we should keep them hollow and not make the classpath adapter "special". Then when we want to use the adapter, we overwrite the hollow stubs in the deploy directory. As I said: > > I think we should be looking to create something, that when > > combined with JCHEVM, can be dropped in to the deploy tree in the > > same way that the current IBM VME is dropped in. HTH, Mark. -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Mark, Sorry I forgot to mention it in the last email. I did the svn diff you suggested below. The results have been attached to Harmony-318. On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > Weldon, > > Sorry, it was a mistake on my part, it should be: > > svn diff --diff-cmd diff -x -ubBw > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > Weldon, > > Sorry, it was a mistake on my part, it should be: > > svn diff --diff-cmd diff -x -ubBw > > Anyway, I'm making some progress with the diff that you already > provided. (Part of the problem was that in order to use the diff on > Linux I had to remove the '\r' characters from the meta-data lines in > the diff.) > > Don't expect me to check anything in. I'm not a committer. > > What I really wanted to do was to: > > 1) bringing your changes up to date with respect to changes/movement > of files in svn, Great! I really appreciate it. > > 2) looking at what you were doing and how, Ah! Sorry for the uncommented code. I wanted to get things working first then go back, clean up and document how they work. I will start working on this part soon. > > 3) test your changes on Linux Good idea. Other than perhaps the arg passing to native methods, there should be zero Linux specific mods. Let me know how things go. > > One thing that makes understanding what you are doing a little > difficult is that you label all your changes with only "// wrw" > comments. Generally I'm more interested in why a change was made than > "who" made it and ultimately svn will keep track of the who (or at > least which committer is to blame! ;-) Good point. I will rip out the //wjw and replace with comments. > > My initial thoughts are that it would be good to eliminate the changes > to you've had to make to the classlib tree and make things easier for > people to try out. Specifically: > > 1) Copy the luni-kernel and security-kernel stubs and add > implementation rather than doing it in place. The stubs are just for > compilation we shouldn't add anything VM (or VM adapter) specific to > them. hmm not sure what you are suggesting. The stubs allow the build to finish properly but the resultant binary won't run on any JVM because the stubs are hollow. > > 2) Figure out how to avoid faking the natives - > e.g. isLittleEndianImpl I assume for lack of 'why' comments that these > relate to the JNI/dll discussions you've been having. Nope. I will have to go back and reconcile why I hacked on isLittleEndianImpl. I can't recall off-hand. > > 3) Rename the java.lang.VM* internals to something more in keeping > with the naming convention [1] something like: > > org.apache.harmony.classpathadapter.internal.VM* No problem with the above renaming. > > 4) Create ant files to build adapter jars: luni-kernel.jar and > security-kernel.jar > > 1), 3), & 4) should be pretty easy to make progress on. I need to > look at 2 in a bit more depth. > > I think we should be looking to create something, that when combined > with JCHEVM, can be dropped in to the deploy tree in the same way that > the current IBM VME is dropped in. > > Anyway, all this is just my (humble) opinion as someone interested in > seeing this progress. All very good ideas. Thanks. > > Regards, > Mark. > > [1] > http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html > > On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > Mark, > > > > Thanks for working on the diffs. I have tried to get svn to behave. > > Version 1.3.0 dated Jan 15 does not recognize the "--diff-cmd" you > > suggest below. It might be a cygwin issue. > > > > Can you check-in just the kernel adapter stubs for now? This should > > involve zero diffs since this is a generic implementation of the > > stubs. There was a discussion previously to put all the kernel_path > > related files below .../enhanced/gnuclasspathadapter/ Thus no worry > > about overwriting the existing empty stubs in Classlib. > > > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > Weldon, any chance you could make a diff_harmony.txt without all the > > > whitespace changes and attach it to the JIRA? I'm trying to update it > > > to work with current svn and I want to avoid going through lots of > > > rejects that are only whitespace changes. I think you should be able > > > to do this with a command like: > > > > > > svn diff --diff-cmd 'diff -ubBw' > > > > > > assuming you have gnu diff installed or you could undo your formatting > > > changes but that might be a little more difficult. ;-) > > > > > > Of course, you realise that the classes you are modifying in kernel > > > (now luni-kernel and security-kernel) are only intended to be stubs to > > > compile against and not implemntation. These are intended to be > > > implemented by the VM. In this case I guess they'd need to be > > > implemented by the adapter. Thus I'm going to copy the stubs and > > > apply your patches to the copy outside of the classlib tree since we > > > shouldn't be changing the stubs. > > > > > > Regards, > > > Mark. > > > > > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > Weldon, > > > > > > > > It's good to have this discussion on the list, but would you mind > > > > including at least some of the
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Weldon, Sorry, it was a mistake on my part, it should be: svn diff --diff-cmd diff -x -ubBw Anyway, I'm making some progress with the diff that you already provided. (Part of the problem was that in order to use the diff on Linux I had to remove the '\r' characters from the meta-data lines in the diff.) Don't expect me to check anything in. I'm not a committer. What I really wanted to do was to: 1) bringing your changes up to date with respect to changes/movement of files in svn, 2) looking at what you were doing and how, 3) test your changes on Linux One thing that makes understanding what you are doing a little difficult is that you label all your changes with only "// wrw" comments. Generally I'm more interested in why a change was made than "who" made it and ultimately svn will keep track of the who (or at least which committer is to blame! ;-) My initial thoughts are that it would be good to eliminate the changes to you've had to make to the classlib tree and make things easier for people to try out. Specifically: 1) Copy the luni-kernel and security-kernel stubs and add implementation rather than doing it in place. The stubs are just for compilation we shouldn't add anything VM (or VM adapter) specific to them. 2) Figure out how to avoid faking the natives - e.g. isLittleEndianImpl I assume for lack of 'why' comments that these relate to the JNI/dll discussions you've been having. 3) Rename the java.lang.VM* internals to something more in keeping with the naming convention [1] something like: org.apache.harmony.classpathadapter.internal.VM* 4) Create ant files to build adapter jars: luni-kernel.jar and security-kernel.jar 1), 3), & 4) should be pretty easy to make progress on. I need to look at 2 in a bit more depth. I think we should be looking to create something, that when combined with JCHEVM, can be dropped in to the deploy tree in the same way that the current IBM VME is dropped in. Anyway, all this is just my (humble) opinion as someone interested in seeing this progress. Regards, Mark. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > Mark, > > Thanks for working on the diffs. I have tried to get svn to behave. > Version 1.3.0 dated Jan 15 does not recognize the "--diff-cmd" you > suggest below. It might be a cygwin issue. > > Can you check-in just the kernel adapter stubs for now? This should > involve zero diffs since this is a generic implementation of the > stubs. There was a discussion previously to put all the kernel_path > related files below .../enhanced/gnuclasspathadapter/ Thus no worry > about overwriting the existing empty stubs in Classlib. > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > Weldon, any chance you could make a diff_harmony.txt without all the > > whitespace changes and attach it to the JIRA? I'm trying to update it > > to work with current svn and I want to avoid going through lots of > > rejects that are only whitespace changes. I think you should be able > > to do this with a command like: > > > > svn diff --diff-cmd 'diff -ubBw' > > > > assuming you have gnu diff installed or you could undo your formatting > > changes but that might be a little more difficult. ;-) > > > > Of course, you realise that the classes you are modifying in kernel > > (now luni-kernel and security-kernel) are only intended to be stubs to > > compile against and not implemntation. These are intended to be > > implemented by the VM. In this case I guess they'd need to be > > implemented by the adapter. Thus I'm going to copy the stubs and > > apply your patches to the copy outside of the classlib tree since we > > shouldn't be changing the stubs. > > > > Regards, > > Mark. > > > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > Weldon, > > > > > > It's good to have this discussion on the list, but would you mind > > > including at least some of the details about what the attached file is > > > in the JIRA comment when you attach a file? At the moment when you > > > look at the JIRA it's hard to tell what the attachments are for? > > > > > > Regards, > > > Mark. > > > > > > On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > I just uploaded a new zip file to JIRA Harmony-318 that contains the > > > > mods to Harmony Classlib that will allow it to run on an unmodified > > > > generic GNU Classpath JVM. > > > > > > > > Some of the issues encountered: > > > > > > > > 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".
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Mark, Thanks for working on the diffs. I have tried to get svn to behave. Version 1.3.0 dated Jan 15 does not recognize the "--diff-cmd" you suggest below. It might be a cygwin issue. Can you check-in just the kernel adapter stubs for now? This should involve zero diffs since this is a generic implementation of the stubs. There was a discussion previously to put all the kernel_path related files below .../enhanced/gnuclasspathadapter/ Thus no worry about overwriting the existing empty stubs in Classlib. On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > Weldon, any chance you could make a diff_harmony.txt without all the > whitespace changes and attach it to the JIRA? I'm trying to update it > to work with current svn and I want to avoid going through lots of > rejects that are only whitespace changes. I think you should be able > to do this with a command like: > > svn diff --diff-cmd 'diff -ubBw' > > assuming you have gnu diff installed or you could undo your formatting > changes but that might be a little more difficult. ;-) > > Of course, you realise that the classes you are modifying in kernel > (now luni-kernel and security-kernel) are only intended to be stubs to > compile against and not implemntation. These are intended to be > implemented by the VM. In this case I guess they'd need to be > implemented by the adapter. Thus I'm going to copy the stubs and > apply your patches to the copy outside of the classlib tree since we > shouldn't be changing the stubs. > > Regards, > Mark. > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > Weldon, > > > > It's good to have this discussion on the list, but would you mind > > including at least some of the details about what the attached file is > > in the JIRA comment when you attach a file? At the moment when you > > look at the JIRA it's hard to tell what the attachments are for? > > > > Regards, > > Mark. > > > > On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > I just uploaded a new zip file to JIRA Harmony-318 that contains the > > > mods to Harmony Classlib that will allow it to run on an unmodified > > > generic GNU Classpath JVM. > > > > > > Some of the issues encountered: > > > > > > 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? > > > > > > 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. > > > > > > > > > > > > -- > > > 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] > > > > > > > > > > > > -- > > Mark Hindess <[EMAIL PROTECTED]> > > IBM Java Technology Centre, UK. > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > 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
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Archie, This helps a bunch! I was getting lost in the JCNI code. Thanks Weldon On 4/12/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: > 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] > > -- 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]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
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]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
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]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
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]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Hi Weldon, Weldon Washburn wrote: > 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? There is nothing specific, as far as I remember. SableVM's native calling code takes care of everything, normally. Have you tried applying your layer to SableVM and see if it works, if it's really a generic layer? Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
WOO! Weldon Washburn wrote: I just uploaded a new zip file to JIRA Harmony-318 that contains the mods to Harmony Classlib that will allow it to run on an unmodified generic GNU Classpath JVM. Some of the issues encountered: 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? 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. -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Weldon, any chance you could make a diff_harmony.txt without all the whitespace changes and attach it to the JIRA? I'm trying to update it to work with current svn and I want to avoid going through lots of rejects that are only whitespace changes. I think you should be able to do this with a command like: svn diff --diff-cmd 'diff -ubBw' assuming you have gnu diff installed or you could undo your formatting changes but that might be a little more difficult. ;-) Of course, you realise that the classes you are modifying in kernel (now luni-kernel and security-kernel) are only intended to be stubs to compile against and not implemntation. These are intended to be implemented by the VM. In this case I guess they'd need to be implemented by the adapter. Thus I'm going to copy the stubs and apply your patches to the copy outside of the classlib tree since we shouldn't be changing the stubs. Regards, Mark. On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > Weldon, > > It's good to have this discussion on the list, but would you mind > including at least some of the details about what the attached file is > in the JIRA comment when you attach a file? At the moment when you > look at the JIRA it's hard to tell what the attachments are for? > > Regards, > Mark. > > On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > I just uploaded a new zip file to JIRA Harmony-318 that contains the > > mods to Harmony Classlib that will allow it to run on an unmodified > > generic GNU Classpath JVM. > > > > Some of the issues encountered: > > > > 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? > > > > 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. > > > > > > > > -- > > 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] > > > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Weldon, It's good to have this discussion on the list, but would you mind including at least some of the details about what the attached file is in the JIRA comment when you attach a file? At the moment when you look at the JIRA it's hard to tell what the attachments are for? Regards, Mark. On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > I just uploaded a new zip file to JIRA Harmony-318 that contains the > mods to Harmony Classlib that will allow it to run on an unmodified > generic GNU Classpath JVM. > > Some of the issues encountered: > > 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? > > 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. > > > > -- > 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] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
I just uploaded a new zip file to JIRA Harmony-318 that contains the mods to Harmony Classlib that will allow it to run on an unmodified generic GNU Classpath JVM. Some of the issues encountered: 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? 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. -- 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]
