This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
debugging custom array types
- From: Michael Haupt <m at haupz dot de>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Mon, 11 Feb 2013 17:51:36 +0100
- Subject: debugging custom array types
Dear all,
in a research project, I'm generating DWARF debug info for machine code generated from Java. Note that I'm not using gcj. I'm using gdb 7.5, mostly on Darwin, but the symptoms are the same on Linux.
I'm having some trouble with my array types. In particular, there are two problems:
1. I would like to generate DWARF info that allows gdb to display array contents.
2. gdb seems to misinterpret valid addresses when they are used in DWARF expressions.
Details follow.
The internal layout of an array instance is as follows:
+0 hub reference (reference to meta-information, e.g., class, vtable, ...)
+8 length
+12 beginning of array contents (offset depends on type, 12 is for char, for instance)
The DWARF I'm generating right now looks as pasted at the end of this message. This is for Java char arrays with the layout given above. Note the __array__ member; its type is a plain TAG_array_type that should be interpreted as embedded.
Now, I cannot for the life of me convince gdb to display the contents of those arrays. I'm pretty sure the DWARF info I'm generating has a problem but cannot figure out what it is. I've been turning things from left to right for a while now.
Here's an excerpt from a debugging session:
(gdb) p slot_1_Object
$1 = java.lang.String@101008910
(gdb) p *slot_1_Object
$2 = {__hub_reference__: @101000070, value: @101008928, hash32: 0}
(gdb) p *slot_1_Object.value
Cannot access memory at address 0x101008928
What I'd have expected here is something of the form {__hub_reference__: ..., __length__: ..., __array__: {...}}, but gdb complains about the address.
Still,
(gdb) x/10xb 0x101008928
0x101008928: 0xe8 0x00 0x00 0x01 0x01 0x00 0x00 0x00
0x101008930: 0x0c 0x00
... so this is definitely not illegal memory. (I can tell from the address it's a valid heap address.)
Grateful for any advice,
Michael
0x00005984: TAG_structure_type [16] *
AT_name( "char_array" )
((1)) AT_byte_size( <0xa> 97 23 08 94 04 08 02 1e 23 0c )
AT_sibling( {0x000059bd} )
0x00005998: TAG_member [10]
AT_name( "__hub_reference__" )
AT_type( {0x00005c9c} ( Lcom/oracle/svm/core/hub/DynamicHub; ) )
AT_data_member_location( +0 )
0x000059a4: TAG_member [10]
AT_name( "__length__" )
AT_type( {0x0000002d} ( base ) )
AT_data_member_location( +8 )
0x000059b0: TAG_member [10]
AT_name( "__array__" )
AT_type( {0x00005a1e} ( char[] ) )
AT_data_member_location( +12 )
0x000059bc: NULL
...
0x00005a1e: TAG_array_type [11] *
AT_type( {0x0000505b} ( char ) )
((2)) AT_byte_size( <0x8> 97 23 08 94 04 08 02 1e )
((3)) AT_data_location( <0x3> 97 23 0c )
AT_sibling( {0x00005a43} )
0x00005a34: TAG_subrange_type [14]
AT_type( {0x0000002d} ( base ) )
((4)) AT_upper_bound( <0x8> 97 23 08 94 04 08 01 1c )
0x00005a42: NULL
The DWARF expressions at ((1))-((4)) each compute the respective values by pushing the object location, dereferencing the __length__ field, multiplying with the array element size, and possibly adding the array base offset.
--
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