harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess" <mark.hind...@googlemail.com>
Subject Re: [classlib] unmodified generic GNU Classpath JVM can now run Classlib "hello world"
Date Wed, 12 Apr 2006 20:20:27 GMT
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 <weldonwjw@gmail.com> 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 <mark.hindess@googlemail.com> 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 <mark.hindess@googlemail.com> 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 <weldonwjw@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Mark Hindess <mark.hindess@googlemail.com>
> > > IBM Java Technology Centre, UK.
> > >
> >
> >
> > --
> > Mark Hindess <mark.hindess@googlemail.com>
> > IBM Java Technology Centre, UK.
> >
> > ---------------------------------------------------------------------
> > 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
>
>


--
Mark Hindess <mark.hindess@googlemail.com>
IBM Java Technology Centre, UK.

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