Re: Bytecode verifier

[Per Bothner <per at bothner dot com>]

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/