gcj and debugging

gcj and debugging

[Michael Haupt]

Hello,

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

Some things I could not figure out.

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

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

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

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

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

BTW I have read a thread on this mailing list from June 2004 (http://gcc.gnu.org/ml/java/2004-06/msg00065.html), which touches upon the subject but does not really address my question.

Thanks,

Michael

-- 
Dr. Michael Haupt
Principal Member of Technical Staff
Phone: +49 331 200 7277, Fax: +49 331 200 7561
Oracle Labs
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany

Re: gcj and debugging

[Andrew Haley]

On 02/01/2013 03:07 PM, Michael Haupt wrote:
> Likewise, how does gdb know how to display a java.lang.String as a, well, string?

Yes to this, but the support seems to have rotted.

Tom Tromey is the right man to answer these questions in detail.  He reads
this list.

Andrew.

Re: gcj and debugging

[Tom Tromey]

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

Re: gcj and debugging

[David Daney]

On 02/07/2013 10:47 AM, Tom Tromey wrote:
>>>>>> "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.
>

Yes.  IIRC, from gdb you have to do:  call degug_????

The exact names of the debug helpers escape me at the moment.

David Daney


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

Re: gcj and debugging

[Michael Haupt]

Tom,

thank you very much for your reply.

Am 07.02.2013 um 19:47 schrieb Tom Tromey <tromey@redhat.com>:
> 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.

Would you suggest to generate DWARF info with the language set to C89 then, to avoid misleading gdb?

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

If gdb's Java language support is really tailored to gcj, it surely assumes internal layout details about arrays. I cannot guarantee that "my" arrays have the same internal representation. :-)

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

Indeed.

Thanks again,

Michael

-- 
Dr. Michael Haupt
Principal Member of Technical Staff
Phone: +49 331 200 7277, Fax: +49 331 200 7561
Oracle Labs
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany

Re: gcj and debugging

[Andrew Haley]

On 02/11/2013 04:26 PM, Michael Haupt wrote:
> Tom,
> 
> thank you very much for your reply.
> 
> Am 07.02.2013 um 19:47 schrieb Tom Tromey <tromey@redhat.com>:
>> 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.
> 
> Would you suggest to generate DWARF info with the language set to C89 then, to avoid misleading gdb?
> 
>> 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.
> 
> If gdb's Java language support is really tailored to gcj, it surely assumes internal layout details about arrays. I cannot guarantee that "my" arrays have the same internal representation. :-)
> 
>> gdb has special code for this.  It looks for a type named
>> "java.lang.String" and then knows what fields it has.
>>
>> Yucky.
> 
> Indeed.

The Right Way to do it, as is done with the thread library, is to have
a target library that GDB opens which contains accessor methods for all
of the VM's structures.

Andrew.

Re: gcj and debugging

[Michael Haupt]

Andrew,

Am 11.02.2013 um 17:32 schrieb Andrew Haley <aph@redhat.com>:
> The Right Way to do it, as is done with the thread library, is to have
> a target library that GDB opens which contains accessor methods for all
> of the VM's structures.

shouldn't DWARF be expressive enough in most cases?

I agree that in order to understand a java.lang.String as a string, some such magic is agreeable, but then I don't really have to have it that comfy. Having gdb print array contents would be wonderful for now. :-) I'm asking about this on the gdb list as it is unrelated to gcj.

Best,

Michael

-- 
Dr. Michael Haupt
Principal Member of Technical Staff
Phone: +49 331 200 7277, Fax: +49 331 200 7561
Oracle Labs
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany