debugging custom array types

[Michael Haupt <m@haupz.de>]

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