[kaffe] BCEL Verifier?

gonzo Robert.N.Gonzalez at williams.edu
Thu Jan 9 18:20:01 PST 2003

Hey Dalibor,

> It runs on kaffe, so you can use the GraphicalVerifier if you add
> swing.jar to the CLASSPATH, or the commandline Verifier to verify
> single classes. But it hasn't been integrated, as in "delegate
> verification to it". It comes under the ASF license, and that one
> supposedly (says FSF) doesn't mix well with the GPL. I wouldn't like
> to start another licensing war ;)

that answers my question :)  it's too bad, because the JustIce verifier is
easily the best free software one out there.

> Anyway, I've used it to verify latest kjc-compiled
> rt.jar. I can post the results online, if anyone is
> interested. They are mostly O.K., except for a few
> rejected methods that need to have someone take a
> close look at them to see if kjc is producing bad
> bytecodes.

i wouldn't mind taking a look, though i offer very little in the way of
kjc knowledge.

> p.s. how is your verifier coming along?

funny you should ask :)  after a good number of months of little work (i
was taking a graphics class that required a pretty enormous amount of
programming), i've finally started picking it up again this week.

pass 2 of verification is mostly done.  the only major thing that still
has to be done is to make sure that all field and method references in
constant pool have valid names, classes, and type descriptors.  which
brings me to one question: does the class loader currently do any of that?

pass 3 (the big one with the data flow analysis) is mostly done.  i'm
still not 100% sure that i'm allocating memory the best way.  at the
moment, i call jthread_diable_stop, then use KALLOC to snag memory for the
verifier, then do my verfication, then call KFREE followed by
jthread_enable_stop at the end.  that sound OK to you?

to ease development i've done the data flow analysis on a per-instruction
basis instead of on a per-basic block basis.  the latter method is both
faster and smaller and wouldn't require too much work to implement, so i'm
definitely going to take care of that before posting.

the last major thing lurking around that i need to fix before posting is
my method of debugging.  rather than spend too much time figuring out
what's going on in debug.[ch], i have a bunch of:
		fprintf(stderr, ...);
	#endif all over the place.
if adding a new flag to -vmdebug called VERIFIER is easy, then i would
like to do that in order to remain consistent with the rest of kaffe.

subroutines (try-finally clauses, etc.) are also not verified correctly
yet, but i'm less worried about them than i am about memory allocation.


More information about the kaffe mailing list