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 22:33:55 GMT
On 4/12/06, Mark Hindess <mark.hindess@googlemail.com> 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 <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
>
>


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