You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/07/06 18:26:35 UTC

[drlvm] verification of classfile format

As part of the work surrounding the HARMONY-677 (r419557), getting DRLVM
to deal with Java5 classfile format,  I noticed that DRLVM doesn't
appear to give a hoot what version of the classfile it's chewing on.  It
just goes until something blows up.

I was comparing to j9, which gives a UnsupportedClassVersionError.
DRLVM should do the same of course, and it makes me worry what else it
outght to be doing - if we don't understand the version of the class
file, how can we read it dependably?

I was reading down through j.l.ClassLoader and natives, and given the
dearth of comments, didn't quite grok where a good place to start doing
some verification would be...  Maybe I missed it.  Can anyone give me a
hint?

geir

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


Re: [drlvm] verification of classfile format

Posted by Alexey Varlamov <al...@gmail.com>.
2006/7/7, Gregory Shimansky <gs...@gmail.com>:
> On Thursday 06 July 2006 20:26 Geir Magnusson Jr wrote:
> > As part of the work surrounding the HARMONY-677 (r419557), getting DRLVM
> > to deal with Java5 classfile format,  I noticed that DRLVM doesn't
> > appear to give a hoot what version of the classfile it's chewing on.  It
> > just goes until something blows up.
>
> It does check the class file version in bootstrap class loader
> (vm/vmcore/src/class_support/Class_File_Loader.cpp) and can throw
> UnsupportedClassVersionError. The constant CLASSFILE_MAJOR_MAX is defined in
> vm/vmcore/include/Class.h.
>
> > I was comparing to j9, which gives a UnsupportedClassVersionError.
> > DRLVM should do the same of course, and it makes me worry what else it
> > outght to be doing - if we don't understand the version of the class
> > file, how can we read it dependably?
>
> For some reason I don't really know the constant was changed to 49 as if VM
> did support class files of version 1.5. Maybe it was the first step to
> support 1.5 classes :)
>
> > I was reading down through j.l.ClassLoader and natives, and given the
> > dearth of comments, didn't quite grok where a good place to start doing
> > some verification would be...  Maybe I missed it.  Can anyone give me a
> > hint?
>
> I think it should happen in bootstrap class loader since it is the place where
> class file parsing is done anyway. So the place is in VM native code, not
> kernel classes.

Just to be accurate, this functionality (class data parsing) is common
to all classloaders, not only bootstrap one (and obviously it would be
a bug, if VM does not check classfiles consistency for user-defined
classloaders). As long as any classloader makes a call to
defineClass(), it will not pass by this check.

--
Alexey Varlamov

> --
> Gregory Shimansky, 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
>
>

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


Re: [drlvm] verification of classfile format

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Gregory Shimansky wrote:
> On Thursday 06 July 2006 20:26 Geir Magnusson Jr wrote:
>> As part of the work surrounding the HARMONY-677 (r419557), getting DRLVM
>> to deal with Java5 classfile format,  I noticed that DRLVM doesn't
>> appear to give a hoot what version of the classfile it's chewing on.  It
>> just goes until something blows up.
> 
> It does check the class file version in bootstrap class loader 
> (vm/vmcore/src/class_support/Class_File_Loader.cpp) and can throw 
> UnsupportedClassVersionError. The constant CLASSFILE_MAJOR_MAX is defined in 
> vm/vmcore/include/Class.h.

Ah ha.  I think I just skipped over class_parse() when reading through :)

> 
>> I was comparing to j9, which gives a UnsupportedClassVersionError.
>> DRLVM should do the same of course, and it makes me worry what else it
>> outght to be doing - if we don't understand the version of the class
>> file, how can we read it dependably?
> 
> For some reason I don't really know the constant was changed to 49 as if VM 
> did support class files of version 1.5. Maybe it was the first step to 
> support 1.5 classes :)

Well, that explains that.  Sorry about that.  My bad.  I've verified
that it works as expected (namely throws the UCVE on a v49 class w/
DRLVM set to v48)

> 
>> I was reading down through j.l.ClassLoader and natives, and given the
>> dearth of comments, didn't quite grok where a good place to start doing
>> some verification would be...  Maybe I missed it.  Can anyone give me a
>> hint?
> 
> I think it should happen in bootstrap class loader since it is the place where 
> class file parsing is done anyway. So the place is in VM native code, not 
> kernel classes.
> 

It seems to be.  Just need some docs, and maybe some tests...

geir

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


Re: [drlvm] verification of classfile format

Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 06 July 2006 20:26 Geir Magnusson Jr wrote:
> As part of the work surrounding the HARMONY-677 (r419557), getting DRLVM
> to deal with Java5 classfile format,  I noticed that DRLVM doesn't
> appear to give a hoot what version of the classfile it's chewing on.  It
> just goes until something blows up.

It does check the class file version in bootstrap class loader 
(vm/vmcore/src/class_support/Class_File_Loader.cpp) and can throw 
UnsupportedClassVersionError. The constant CLASSFILE_MAJOR_MAX is defined in 
vm/vmcore/include/Class.h.

> I was comparing to j9, which gives a UnsupportedClassVersionError.
> DRLVM should do the same of course, and it makes me worry what else it
> outght to be doing - if we don't understand the version of the class
> file, how can we read it dependably?

For some reason I don't really know the constant was changed to 49 as if VM 
did support class files of version 1.5. Maybe it was the first step to 
support 1.5 classes :)

> I was reading down through j.l.ClassLoader and natives, and given the
> dearth of comments, didn't quite grok where a good place to start doing
> some verification would be...  Maybe I missed it.  Can anyone give me a
> hint?

I think it should happen in bootstrap class loader since it is the place where 
class file parsing is done anyway. So the place is in VM native code, not 
kernel classes.

-- 
Gregory Shimansky, 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