Bytecode verifier

Thu Mar 18 21:49:00 GMT 2004

Andrew Haley wrote:
> Perhaps we could have a separate verification pass in gcj -- verify
> first using the libgcj verifier and then do separate semantic
> analysis. That's better than trying to maintain two buggy verifiers.

I agree that would be better to have one verifier than two. And since
I can't afford to maintain the one I wrote on my own time (and I don't
have has much current understanding of the issues as Tom) I won't be
too upset if you choose Tom's. Slightly wistful, as java/gcc/verify.c
is more compact (both source and binary) and possibly more efficient,
though that isn't too relevant if fixing it would require major work.
> I don't think the fact that the libgcj verifier is written in C++ is a
> show stopper. We could have a verifer library and compile it twice,
> once for host and once for target.

If avoiding a dependency of C++ during bootstrapping is desirable,
you can always compile without verification in the first pass - though
I don't think that's a real issue.
Tom Tromey wrote:
 > We can just maintain one buggy verifier :-). I won't claim that the
 > libgcj verifier is bug-free, just that it uses a model that lets us
 > avoid the most common bugs. In particular it does type unions, not
 > type merges;
Something I always wanted to do, at least for handling interfaces,
but never got around to.
 > and it does subroutine splitting, avoiding the common
 > pitfalls and misconceptions around subroutine verification (the
 > subroutine problems particularly affect the gcj verifier).
Those were always the hardest problems.
-- 
	--Per Bothner
per@bothner.com http://per.bothner.com/