[ Not subbed, please CC me on replies. ]

    Hello Java team,

  The attached patch fixes the first build problem I run into after turning on
"--enable-libgcj-debug":

[ ... ] -DPIC -o gnu/classpath/jdwp/.libs/natVMVirtualMachine.o
/gnu/gcc/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc: In function
'void handle_single_step(jvmtiEnv*, step_info*, java::lang::Thread*,
_Jv_Method*, jlocation)':
/gnu/gcc/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:903: error:
request for member 'frame_type' in 'thread->java::lang::Thread::frame', which
is of non-class type 'gnu::gcj::RawData*'
/gnu/gcc/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc: In function
'void jdwpBreakpointCB(jvmtiEnv*, JNIEnv*, java::lang::Thread*, _Jv_Method*,
jlocation)':
/gnu/gcc/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:960: error:
request for member 'frame_type' in 'thread->java::lang::Thread::frame', which
is of non-class type 'gnu::gcj::RawData*'
make[3]: *** [gnu/classpath/jdwp/natVMVirtualMachine.lo] Error 1

  It looks like a couple of asserts didn't get updated at some point when the
class definition was reorganised.  The member they are trying to test is
easily available from the reinterpreted pointer, so I used that instead.

libjava/ChangeLog:

	* gnu/classpath/jdwp/natVMVirtualMachine.cc (handle_single_step):  Use
	casted pointer in debugging assert.
	(jdwpBreakpointCB):  Likewise.

  Tested on i686-pc-cygwin by resuming a failed build and seeing it get
further.  I haven't been able to test the assert in practice yet because I
only get a bit further before running into problem #2, and it occurs to me
that maybe it's entirely superfluous now as the reinterpret_cast will throw a
typeinfo exception if we pass the wrong kind of frame object to it, won't it?
 So perhaps just deleting the asserts would be better.

  I'll describe problem #2 in a follow-up post.

    cheers,
      DaveK