[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

Andrew Burgess <andrew.burgess at embecosm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrew.burgess at embecosm dot com

--- Comment #10 from Andrew Burgess <andrew.burgess at embecosm dot com> ---
I think Tom's fix makes sense.  The reason I don't think we've run into this
before is that the way the 2 dimensional array is being represented is not
similar to what we see in (say) Fortran.

To expand on the DWARF Simon posted, here's the same thing plus a little extra:

  <1><ac>: Abbrev Number: 2 (DW_TAG_variable)
     <ad>   DW_AT_name        : (indirect string, offset: 0x71): ref2dim
     <b1>   DW_AT_type        : <0xc8>
     <b5>   DW_AT_decl_file   : 1
     <b6>   DW_AT_decl_line   : 1
     <b7>   DW_AT_location    : 12 byte block: 3 10 60 7 0 0 0 0 0 23 90 5     
 (DW_OP_addr: 76010; DW_OP_plus_uconst:>
     <c4>   DW_AT_linkage_name: (indirect string, offset: 0x71): ref2dim
  <1><c8>: Abbrev Number: 7 (DW_TAG_pointer_type)
     <c9>   DW_AT_type        : <0xd1>
     <cd>   DW_AT_name        : (indirect string, offset: 0x85): RefDynArr2
  <1><d1>: Abbrev Number: 8 (DW_TAG_array_type)
     <d2>   DW_AT_data_location: 2 byte block: 97 6     
(DW_OP_push_object_address; DW_OP_deref)
     <d5>   DW_AT_type        : <0xea>
  <2><d9>: Abbrev Number: 9 (DW_TAG_subrange_type)
     <da>   DW_AT_type        : <0x60>
     <de>   DW_AT_name        : (indirect string, offset: 0x79): DynArr2_rng
     <e2>   DW_AT_lower_bound : 1 byte block: 30         (DW_OP_lit0)
     <e4>   DW_AT_count       : 4 byte block: 97 23 8 6 
  <2><e9>: Abbrev Number: 0
  <1><ea>: Abbrev Number: 8 (DW_TAG_array_type)
     <eb>   DW_AT_data_location: 2 byte block: 97 6     
(DW_OP_push_object_address; DW_OP_deref)
     <ee>   DW_AT_type        : <0x60>
  <2><f2>: Abbrev Number: 9 (DW_TAG_subrange_type)
     <f3>   DW_AT_type        : <0x60>
     <f7>   DW_AT_name        : (indirect string, offset: 0x5a): DynArr1_rng
     <fb>   DW_AT_lower_bound : 1 byte block: 30         (DW_OP_lit0)
     <fd>   DW_AT_count       : 4 byte block: 97 23 10 6 
  <2><102>: Abbrev Number: 0

The interesting thing here that I don't see from Fortran is that the 2
dimensions are represented as a DW_TAG_array_type that has a DW_AT_type that is
also a DW_TAG_array_type.  Each array_type has a single DW_TAG_subrange_type,
and each array has its own DW_AT_data_location.  I guess this allows for the
possibility that each dimension of the array might be stored at disjoint
locations in memory??

In Fortran we usually see a single DW_TAG_array_type with multiple
DW_TAG_subrange_type children (one per dimension).  The array will have a
DW_AT_data_location (so just one for the whole array).

However, inside GDB we do model multi-dimensional arrays as arrays of arrays,
this can be seen in dwarf/read.c:read_array_type.  The first DW_TAG_array_type
and DW_TAG_subrange_type create the first GDB ARRAY type object, and each
additional DW_TAG_subrange_type creates a new ARRAY type object which is the
TARGET_TYPE of the more outer array dimension.  What this means is that we
(previously) only expected to see DW_AT_data_location on the first GDB ARRAY
type object.  Each additional level of ARRAY type would not have a data
location (and so would use the location of its more outer array level).

I had a read through the DWARF spec for arrays and though the approach being
taken here is unusual (i.e. I don't see it discussed as a possible way to
represent multi-dimensional arrays in the spec) I don't see any reason why this
should be prohibited.  As such Tom's suggested change seems reasonable to me.

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