patch to bring java vtables closer to g++ abi conformance

[Per Bothner]

Tom Tromey wrote:
> I don't have a problem with doing this.
> However, won't we also need a corresponding runtime patch?

At some point.  But I don't believe the patch breaks anything that
currently works.  Both the vtable field in individual objects, and
the class-vtable field in a Class point to the +8 address, so
only code that looks to see what is in those 8 bytes or looks
at the symbol table will be affected.  The former couldn't have
worked (since those 8 bytes didn't exist); the latter is unlikely.

> The interpreter creates vtables at runtime.

Yes, those should be fixed too - but it isn't urgent.  And as Hans
says - that requires doing it in a gc-aware manner.  So I'm not
planning on doing this work myself.

This is clearly not a complete fix - but it brings us closer,
without (I believe) breaking anything, and is even binary compatible.

> Also, we create array vtables at runtime by copying the Object vtable;
> if the debugger relies on these extra entries then we'll need the
> runtime patch even for compiled code.

As far as I know, the debugger doesn't actually depend on those
entries.  What it does to determine the actual class of an object
reference is follow the object's vtable pointer, and demangle the
symbol (if any) it points to.  So for dynamically generated vtables
it's not going to find the symbol.  Using the actual rtti information
would of course be better.

My goal for dynamically loaded classes is to use a JIT.  That
will make stack traces etc correct.  We still need a mechanism for
gdb to get the symbol table of the generated code.  This could be
done by extending the existing shared library mechanism.  (I.e.
treat the JIT-generated code as if it were created by dlopen.)
Alternatively use reflective data structures - which is why it
might be nice to integrate Java reflection and C++ rtti.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/