[Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array

["andrew.burgess at embecosm dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27049

--- Comment #11 from Andrew Burgess <andrew.burgess at embecosm dot com> ---
Created attachment 13059
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13059&action=edit
Test case.

I wrote a test for this issue (see attached).  And after writing this I
realised that Tom's proposed solution is not going to do what we'd want it to
do.

To explain, here we have the important bits from the DWARF representing our
array of arrays.  Then I have the memory contents, with addresses on the left,
and contents on the right.

-------------------------------------

($0) VARIABLE
=============
DW_AT_location: 0x1000
DW_AT_type: $1

($1) ARRAY
==========
subrange: lower_bound = 1, count = 4
DW_AT_data_location: DW_OP_push_object_address; DW_OP_deref
DW_AT_type: $2

($2) ARRAY
==========
subrange: lower_bound = 1, count = 4
DW_AT_data_location: DW_OP_push_object_address; DW_OP_deref
DW_AT_type: $3

($3) INTEGER
============
size: 4
signed: true

-------------------------------------

...
0x1000:   0x2000
...
0x2000:   0x3000
0x2004:   0x4000
...
0x3000:   0
0x3004:   1
0x3008:   2
0x300c:   3
...
0x4000:   0
0x4004:   1
0x4008:   2
0x400c:   3
...

-------------------------------------

The variable $0 is at address 0x1000.  At this address is a pointer to an array
of pointers.  Each of these pointers points to a separate dimension of the
array, one at address 0x3000 and one at 0x4000.  The complete array is NOT in
one contiguous block in memory.

I am representing the array this way as it is my assumption that this is the
only reason for giving each of the nested array types their own
DW_AT_data_location.


The problem we have is that currently inside GDB we have the variable ($0)
which has dynamic type.  When we want to use this variable we call
resolve_dynamic_type and pass in the address of the variable $0.

When we resolve the DW_AT_data_location for the outer array type ($1) we use
the address of the variable $0 as the value pushed when we execute
DW_OP_push_object_address.

Next we try to resolve the element type of the array.  This is the problem, an
array has a single element type.  But if you look at the above then each 2nd
rank array can have its own separate data location.  As we currently store the
resolved data location on the type then we can only support a single data
location for all elements.

What currently happens with Tom's patch is that when resolving the element type
we re-use the address of the variable $0 as the object address, each of the 2nd
rank array types then points to the same area of memory, in our example above
this would be the address 0x2000.

-- 
You are receiving this mail because:
You are on the CC list for the bug.