debugging custom array types

debugging custom array types

[Michael Haupt]

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

Re: debugging custom array types

[Jan Kratochvil]

On Mon, 11 Feb 2013 17:51:36 +0100, Michael Haupt wrote:
> 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)

THis means the type length is stored in inferior memory.  I call it 'dynamic
type', FSF GDB does not support it, it is supported in
archer-jankratochvil-vla from
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
or in any Fedora GDB.

But FSF GDB generally displays such arrays as pointers instead:

34	foo (int size) {
36	  char temp1[size];
FSF GDB:
(gdb) p temp1
$1 = 0x7fffffffd9e0 "XXX"
(gdb) ptype temp1
type = char []
archer-jankratochvil-vla:
(gdb) p temp1
$1 = "XXX"
(gdb) ptype temp1
type = char [26]


> The DWARF I'm generating right now looks as pasted at the end of this message.

Could you display it with GNU binutils "readelf -wi"?  There aren't the DWARF
expressions decoded so it is not easy to read what you have there.

BTW such dynamic types are in the archer-jankratochvil-vla branch above, for a
simple one see gdb.base/vla.exp.

 <1><12c>: Abbrev Number: 11 (DW_TAG_array_type)
    <12d>   DW_AT_type        : <0x49>  
 <2><135>: Abbrev Number: 12 (DW_TAG_subrange_type)
    <136>   DW_AT_type        : <0x34>  
    <13a>   DW_AT_upper_bound : 3 byte block: 91 48 6   (DW_OP_fbreg: -56; DW_OP_deref)
 <2><13e>: Abbrev Number: 0



Regards,
Jan

Re: debugging custom array types

[Michael Haupt]

Jan,

thanks a lot, this is most enlightening ...

Am 11.02.2013 um 18:02 schrieb Jan Kratochvil <jan.kratochvil@redhat.com>:
> On Mon, 11 Feb 2013 17:51:36 +0100, Michael Haupt wrote:
>> 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)
> 
> THis means the type length is stored in inferior memory.  I call it 'dynamic
> type', FSF GDB does not support it, it is supported in
> archer-jankratochvil-vla from
> 	http://sourceware.org/gdb/wiki/ArcherBranchManagement
> or in any Fedora GDB.

Is there documentation somewhere that explicates which pieces of DWARF gdb supports out of the box? I'm not opposed to patching it but would like to know better what to (not) expect.

>> The DWARF I'm generating right now looks as pasted at the end of this message.
> 
> Could you display it with GNU binutils "readelf -wi"?  There aren't the DWARF
> expressions decoded so it is not easy to read what you have there.

Sure; sorry about having missed that. It's pasted below. Interestingly the byte_size DWARF expressions are not interpreted.

The one in char_array looks as follows:
DW_OP_push_object_address
DW_OP_plus_uconst: 8
DW_OP_deref_size: 4
DW_OP_const1u: 2
DW_OP_mul
DW_OP_plus_uconst: 12

The one in the array type, as follows:
DW_OP_push_object_address
DW_OP_plus_uconst: 8
DW_OP_deref_size: 4
DW_OP_const1u: 2
DW_OP_mul

Best,

Michael



 <1><5320>: Abbrev Number: 16 (DW_TAG_structure_type)
    <5321>   DW_AT_name        : (indirect string, offset: 0x177): char_array   
    <5325>   DW_AT_byte_size   : 10 byte block: 97 23 8 94 4 8 2 1e 23 c        
    <5330>   DW_AT_sibling     : <0x5359>       
 <2><5334>: Abbrev Number: 10 (DW_TAG_member)
    <5335>   DW_AT_name        : (indirect string, offset: 0xdc): __hub_reference__     
    <5339>   DW_AT_type        : <0x5c6f>       
    <533d>   DW_AT_data_member_location: 2 byte block: 23 0     (DW_OP_plus_uconst: 0)
 <2><5340>: Abbrev Number: 10 (DW_TAG_member)
    <5341>   DW_AT_name        : (indirect string, offset: 0x185): __length__   
    <5345>   DW_AT_type        : <0x2d> 
    <5349>   DW_AT_data_member_location: 2 byte block: 23 8     (DW_OP_plus_uconst: 8)
 <2><534c>: Abbrev Number: 10 (DW_TAG_member)
    <534d>   DW_AT_name        : (indirect string, offset: 0x195): __array__    
    <5351>   DW_AT_type        : <0x5a6c>       
    <5355>   DW_AT_data_member_location: 2 byte block: 23 c     (DW_OP_plus_uconst: 12)
...
 <1><5a6c>: Abbrev Number: 11 (DW_TAG_array_type)
    <5a6d>   DW_AT_type        : <0x4f11>       
    <5a71>   DW_AT_byte_size   : 8 byte block: 97 23 8 94 4 8 2 1e      
    <5a7a>   DW_AT_data_location: 3 byte block: 97 23 c         (DW_OP_push_object_address; DW_OP_plus_uconst: 12)
    <5a7e>   DW_AT_sibling     : <0x5a91>       
 <2><5a82>: Abbrev Number: 14 (DW_TAG_subrange_type)
    <5a83>   DW_AT_type        : <0x2d> 
    <5a87>   DW_AT_upper_bound : 8 byte block: 97 23 8 94 4 8 1 1c      (DW_OP_push_object_address; DW_OP_plus_uconst: 8; DW_OP_deref_size: 4; DW_OP_const1u: 1; DW_OP_minus)




-- 
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: debugging custom array types

[Tom Tromey]

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

Michael> Is there documentation somewhere that explicates which pieces of DWARF
Michael> gdb supports out of the box?

There isn't.

We've made some effort over the last few years to support more of DWARF,
but there are still holes (some mentioned in bugzilla).  Usually the
holes are either because the implementation is very hard (the VLA work
falls into this category) or because no compiler has ever been seen to
emit the DWARF in question.

Michael> DW_OP_push_object_address

This one is still unimplemented, one of the few remaining DW_OP_ holes.

Tom

Re: debugging custom array types

[Michael Haupt]

Tom,

Am 13.02.2013 um 18:51 schrieb Tom Tromey <tromey@redhat.com>:
> We've made some effort over the last few years to support more of DWARF,
> but there are still holes (some mentioned in bugzilla).  Usually the
> holes are either because the implementation is very hard (the VLA work
> falls into this category) or because no compiler has ever been seen to
> emit the DWARF in question.

I see.

> Michael> DW_OP_push_object_address
> 
> This one is still unimplemented, one of the few remaining DW_OP_ holes.

OK. Is it safe to assume that the VLA work Jan keeps mentioning on this thread will eventually make it into gdb "proper" (or FSF gdb or whatever the correct name is)? Is there an idea of how long it might take?

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: debugging custom array types

[Tom Tromey]

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

Michael> OK. Is it safe to assume that the VLA work Jan keeps mentioning on
Michael> this thread will eventually make it into gdb "proper" (or FSF gdb or
Michael> whatever the correct name is)? Is there an idea of how long it might
Michael> take?

It will go in eventually, but probably in a different form.
I don't know how long it will take.  It really needs a rewrite.

It may help with the problem you are facing, but it won't solve it.
That's because the jv-* code in gdb will still be wrong.  There's no way
to avoid fixing this, unless you want to have arrays that are laid out
exactly the same way that gcj does it.

For example, see the BINOP_SUBSCRIPT case in
jv-lang.c:evaluate_subexp_java.  This is the code that handles
expressions like "x[5]":

	  address = value_as_address (arg1);
	  address += get_java_object_header_size (exp->gdbarch);
	  read_memory (address, buf4, 4);
	  length = (long) extract_signed_integer (buf4, 4, byte_order);
	  index = (long) value_as_long (arg2);
[...]
	  address = (address + 4) + index * TYPE_LENGTH (el_type);

This is all pretty bogus; as you can see it pretty much directly knows
about array class layout.  Gross.

I think this code is actually broken right now.  At least, a simple test
made it seem like array subscripting just doesn't work even for gcj any
more.

Tom

Re: debugging custom array types

[Jan Kratochvil]

On Wed, 13 Feb 2013 11:50:34 +0100, Michael Haupt wrote:
> Is there documentation somewhere that explicates which pieces of DWARF gdb
> supports out of the box?

No, read the source.


>  <1><5320>: Abbrev Number: 16 (DW_TAG_structure_type)
>     <5321>   DW_AT_name        : (indirect string, offset: 0x177): char_array   
>     <5325>   DW_AT_byte_size   : 10 byte block: 97 23 8 94 4 8 2 1e 23 c        
>     <5330>   DW_AT_sibling     : <0x5359>       
>  <2><5334>: Abbrev Number: 10 (DW_TAG_member)
>     <5335>   DW_AT_name        : (indirect string, offset: 0xdc): __hub_reference__     
>     <5339>   DW_AT_type        : <0x5c6f>       
>     <533d>   DW_AT_data_member_location: 2 byte block: 23 0     (DW_OP_plus_uconst: 0)
>  <2><5340>: Abbrev Number: 10 (DW_TAG_member)
>     <5341>   DW_AT_name        : (indirect string, offset: 0x185): __length__   
>     <5345>   DW_AT_type        : <0x2d> 
>     <5349>   DW_AT_data_member_location: 2 byte block: 23 8     (DW_OP_plus_uconst: 8)
>  <2><534c>: Abbrev Number: 10 (DW_TAG_member)
>     <534d>   DW_AT_name        : (indirect string, offset: 0x195): __array__    
>     <5351>   DW_AT_type        : <0x5a6c>       
>     <5355>   DW_AT_data_member_location: 2 byte block: 23 c     (DW_OP_plus_uconst: 12)
> ...
>  <1><5a6c>: Abbrev Number: 11 (DW_TAG_array_type)
>     <5a6d>   DW_AT_type        : <0x4f11>       
>     <5a71>   DW_AT_byte_size   : 8 byte block: 97 23 8 94 4 8 2 1e      
>     <5a7a>   DW_AT_data_location: 3 byte block: 97 23 c         (DW_OP_push_object_address; DW_OP_plus_uconst: 12)
>     <5a7e>   DW_AT_sibling     : <0x5a91>       
>  <2><5a82>: Abbrev Number: 14 (DW_TAG_subrange_type)
>     <5a83>   DW_AT_type        : <0x2d> 
>     <5a87>   DW_AT_upper_bound : 8 byte block: 97 23 8 94 4 8 1 1c      (DW_OP_push_object_address; DW_OP_plus_uconst: 8; DW_OP_deref_size: 4; DW_OP_const1u: 1; DW_OP_minus)

Even archer-jankratochvil-vla branch does not support dynamic structures:
dwarf2read.c:
read_structure_type:
  attr = dwarf2_attr (die, DW_AT_byte_size, cu);
  if (attr)
    {
      TYPE_LENGTH (type) = DW_UNSND (attr);
    }

That DW_TAG_array_type/DW_TAG_subrange_type with dynamic DW_AT_upper_bound
should be supported but not as a directly embedded part of struct.

BTW archer-jankratochvil-vla is generally wrong, its reimplementation was
discussed in:
	plan: VLA (Variable Length Arrays) and Fortran dynamic types
	http://sourceware.org/ml/gdb/2012-11/msg00094.html


Regards,
Jan

Re: debugging custom array types

[Michael Haupt]

Jan,

Am 13.02.2013 um 18:58 schrieb Jan Kratochvil <jan.kratochvil@redhat.com>:
> That DW_TAG_array_type/DW_TAG_subrange_type with dynamic DW_AT_upper_bound
> should be supported but not as a directly embedded part of struct.

if I'm not totally mistaken (which I would not preclude), Appendix D.2.1 of the DWARF standard document suggests otherwise.

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

Re: debugging custom array types

[Jan Kratochvil]

On Thu, 14 Feb 2013 14:37:56 +0100, Michael Haupt wrote:
> Am 13.02.2013 um 18:58 schrieb Jan Kratochvil <jan.kratochvil@redhat.com>:
> > That DW_TAG_array_type/DW_TAG_subrange_type with dynamic DW_AT_upper_bound
> > should be supported but not as a directly embedded part of struct.
> 
> if I'm not totally mistaken (which I would not preclude), Appendix D.2.1 of
> the DWARF standard document suggests otherwise.

Yes, the example from Appendix D.2.1 is not supported by
archer-jankratochvil-vla.


Jan

Re: debugging custom array types

[Tom Tromey]

>>>>> "Michael" == Michael Haupt <m@haupz.de> writes:

Michael> 1. I would like to generate DWARF info that allows gdb to
Michael> display array contents.

If you are emitting DW_LANG_Java, then you are going to have to modify
gdb.  gdb currently "knows" that Java means gcj -- and it knows this in
a particularly awful way.

Search gdb/jv-*.c for "array".  I think there aren't *that* many places
to modify.

Tom