Re: _Jv_Debug

[Andrew Haley <aph at redhat dot com>]

Per Bothner writes:
 > Andrew Haley wrote:
 > 
 > > With this in mind, I have created _Jv_Debug, which does something
 > > similar.
 > 
 > I think this is the wrong name: you're not "debugging" the object,
 > just "printing" it.  Perhaps _Jv_DisplayFields ? or just _Jv_Display ?
 > Actually, we should probably use a Jv name rather than a _Jv_ name.

Okay.  It's only really debugger visible anyway.

 > Most of the time you probably don't want the static fields,
 > especially not constant fields, so you'd want a variant or option
 > to control this.

True.

 >    In gdb you can do this:
 > > 
 > > (gdb) p _Jv_Debug(0x80a9890)
 > > ...
 > > 
 > > which is rather nice, I think.  [There is a small problem -- gdb won't
 > > let you call a function in the inferior when you're in "java mode".
 > > You have to do "set lang c++".  We should easily be able to fix this
 > > in gdb.]
 > 
 > I really would rather fix gdb to print objects automatically.
 > If it has to invisibly call a runtime routine to do so, that is
 > tolerable, though obviously not ideal.

That's the idea, yes.

 > For one thing it won't work on a core file or otherwise dead
 > executable.
 > 
 > But time/money are limited ...
 > 
 > > The new ABI has dynamic object structures, and so it will be hard for
 > > gdb to print their contents: the static debugging data will be
 > > useless.  This method is a way to solve that problem.
 > 
 > It's a kludge, not a solution.

Well, it's a kludge that solves a problem  :-)

 > It would be nice to be able to spend the time to do it right.
 > 
 > An alternative is to use the run-time meta-data,

Eventually, gdb may use that.  But there's a lot to be said for
calling a function in the inferior, although I take your point about
the diadvantages.

 > which has the advantage of also working with interpreted (or JIT'd)
 > code, but the disadvantage of tying gdb to the meta-data format,
 > and not working for (future) code compiled without meta-data.

Indeed.  As part of the ABI, I guess we'll also need a debugger
interface.  JVMDI, anyone...

Andrew.