Patch: RFC: verifier genericization

[Tom Tromey <tromey at redhat dot com>]

This patch shows one possible way to make the verifier more generic.
This is a step toward letting other VMs use it, and toward
incorporating it into the gcj front end, so we only have to fix
verifier bugs (see 12734 and 13378; note that 13274 is a bug in the
eclipse compiler as far as I can tell) in one place.

I haven't written a ChangeLog entry yet, I wanted to hold off on that
until it is ready to be checked in.

The patch is pretty ugly as-is.  The changes to verify.cc are
semi-mechanical, basically changing most places that know about libgcj
to instead use a new suite of `vfy_' functions and types that abstract
out the type system.

verify.h is the ugly part.  The intent is to make it possible to plug
the verifier into a pure C program like gcc.  So, I made the initial
API C-like, just some types and simple function calls.

This is achievable for the most part, except that vfy_fail() has to
throw an exception (and a real one, not longjmp, due to the use of
destructors in verify.cc).  So even in gcc some small bit of glue will
need to be in C++.  (This can be isolated from the C code, though, so
I don't think we'll need to make all the gcc header files C++-safe or
anything drastic like that.)

However, while writing the particular verify.h for libgcj itself, I
discovered I would need to add a lot of `friend' declarations in
various places.  This looked pretty ugly, in particular ordering our
special typedefs and the includes of other headers to get the
declarations all in the right order was going to be gross.

So, I ended up adding a bunch of `#define's so that we could put all
the needed helper functions into a single new class, which we then
declare as a friend in the appropriate places.

But is this really better than the alternatives?

One alternative that might be cleaner is to simply require each user
of the verifier to write a base class (not a derived class, which
might seem more usual, since IMO we don't want to mess with virtual
methods for this stuff, but rather we should continue our grand
tradition of micro-optimization :-) with a given name, from which
_Jv_BytecodeVerifier derives.

This would imply either making gcc safe for C++ (a worthy goal in its
own right, assuming it hasn't already been done), or writing another
layer of indirection in the gcc glue code (yuck).

I've also attached a verify.h and verify-glue.c that could be used for
gcc.  These compiled a few months back when I wrote them, no promises
now... they're for informative purposes only, to show a possible
implementation direction on the gcj side.  (And, sorry Bryce, I didn't
work on the really nasty bit, which is changing the build system to
allow a C++ file in a gcc front end.)

We'll want more documentation in verify.h or perhaps verify.cc, so
that it is even more clear what is going on and how other folks can
re-use the verifier in their implementations.

Tom

Attachment: P
Description: verifier patch

Attachment: verify-glue.c
Description: sample gcc glue code

Attachment: verify.h
Description: sample gcc header