This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: _Jv_Debug

Andrew Haley wrote:

With this in mind, I have created _Jv_Debug, which does something

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.

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.

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. 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.

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, 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.
	--Per Bothner

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]