[kaffe] bytecode verifier

gonzo Robert.N.Gonzalez at williams.edu
Mon Jul 22 13:24:15 PDT 2002

btw - what does the "notyet" mean (code-analyse.h)?  there are a couple of
source files in the project that have "#if defined(notyet)", though i
can't find anywhere where it would potentially be defined.  is this
kaffe-specific notation?  (ie - put #if defined(notyet)" around code that
you don't want to use yet?)

> I'd like to cite from the cvs log for the pocketlinux
> kaffe code-analyse2.c file:
> * Major reworking of verifier:
> 	1. Removed code-analyse.c which didn't really do
> anything useful
> so a merge with that code might be interesting.

i looked into this, and although one of the CVS notes mentioned that
code-analyse.c was removed, development seemed to continued on it for
months afterwards.  i haven't looked into it much beyond that, but it
makes me a little suspicious about that particular commit.

to potentially save me some time, does anyone know about the state of the
pocketlinux verifier off the top of your head?  if not, then i can go bug
their developers :)

> On the other hand, there is a patch that adds full
> bytecode verification for kaffe 1.0.6:
> http://www.kaffe.org/pipermail/kaffe/2001-August/007391.html

i spent some time this morning looking at this, and porting the patch to
version 1.0.7 won't be too difficult at all. i'll get back to you
regarding its completenss once i've had time to test it out.

> As you are most likely to call the verifier API from
> ClassLoader.defineClass(byte [], int off, int len),
> the natural choice for the verifier method is
> verify(byte [] code, int off, int len). then you'd
> have to write a VerifierManager, that essentially has
> a single static method returning the current (system
> property kaffe.verifier) verifier, and a class for
> each verifier that manages argument passing. It should
> be about a week of work altogether to get it into a
> releasable form.

are you sure about this?  according to the JVM specs, verification
occurs at link time, which means that the API would be called from
classMethod.'s processClass(). i want to make sure i'm putting the calls
in the right place before investing too much effort in the verification

btw - dalibor, thanks a bunch for getting back to me with so much info.
i'm pretty excited to get to work with you guys on this :)


More information about the kaffe mailing list