Re: gcj and debugging

[Tom Tromey <tromey@redhat.com>]

>>>>> "Michael" == Michael Haupt <michael.haupt@oracle.com> writes:

Michael> in a research project, I'm generating DWARF debugging info for machine
Michael> code generated from Java. I looked at some of the DWARF debug info
Michael> generated by gcj (including that contained in libgcj.so).

I think the first thing to realize is that the gdb support for Java was
all written to target gcj specifically, and also written long ago and
then barely updated.

It isn't very general or done the way it would be done now.
It was never updated for the gcj binary compatibility ABI.

Michael> Java arrays are all merely declared in the DWARF; structural
Michael> information about Java array objects is not given. In libgcj's
Michael> array.h, there are two classes, __JArray and JArray<T> (inheriting
Michael> from __Jarray), that hold a length field and, in addition, a T*
Michael> array[0].

Michael> The debug info for libgcj does not contain any structural information
Michael> about these two classes.

Michael> How does gdb determine that there is a length field, and how many
Michael> elements there are if the length is assigned dynamically? I reckon the
Michael> latter can be done by describing the length as a DWARF exprloc, but
Michael> the description is nowhere to be found.

I thought things like "print array[0]" used to work, but even that seems
to fail for me now.  There is definitely some code for this in gdb, see
jv-valprint.c:java_value_print.  It seems to know a bit about array
layout and then goes from there (though the code looks somewhat bogus to
me...).  See also jv-lang.c:evaluate_subexp_java for the code that tries
to do array subscripting.

Without debugging more I couldn't say why it is broken.

Michael> How does the DWARF description of a Java array look?
Michael> Is this generated at run-time somehow?
Michael> Do gcj-generated binaries and gdb interact in some other ways than
Michael> through DWARF when it comes to meta-info exchange?

I believe gdb can also read some of the gcj runtime metadata and
construct type information from this.  The code here seems pretty
minimal though.

Michael> Likewise, how does gdb know how to display a java.lang.String as a,
Michael> well, string?

gdb has special code for this.  It looks for a type named
"java.lang.String" and then knows what fields it has.

Yucky.

Nowadays I'd be more tempted to implement string-printing using Python.
_Jv_Utf8Const could be handled this way too.

Tom