From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A11003896C12; Fri, 18 Dec 2020 01:19:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A11003896C12 From: "peter.mckinna at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug m3/27049] gdb crashes when printing variable of 2 dimensional dynamic array Date: Fri, 18 Dec 2020 01:19:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: m3 X-Bugzilla-Version: 10.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: peter.mckinna at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2020 01:19:00 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27049 --- Comment #12 from peter mckinna --- The thing is - it works. I don't know of any language that uses more than one dope vector to describe a dynamic array and that's where the data loc is stored. Imagine if there was one dope vector per dimension. Allocations would be a lot more inefficient and complex, not to mention array access. Indirecting though multiple vectors to calc the address of an element would be crazy. So in practice, I think there will always only ever be one allocation. That said, it makes sense that the data loc belongs to the outermost dimension array type. It was trivial for my test to remove all the data loc tags for the inner arrays and gdb still worked. So I think one could safely ignore them if they exist. Dwarf is a loose spec after all. As an aside. It surprised me when I first saw the fortran Dwarf for a multiple dim array and it had all the subranges for the array as children. I couldn't find a mention in the spec to support that arrangement and it seemed to depend on the lexical ordering of the subrange as to which dimension it applied. I mean subrange does not have an attribute saying it applies to index x or whatever. On Fri, 18 Dec 2020 at 04:30, andrew.burgess at embecosm dot com < sourceware-bugzilla@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=3D27049 > > --- Comment #11 from Andrew Burgess > --- > Created attachment 13059 > --> https://sourceware.org/bugzilla/attachment.cgi?id=3D13059&action=3D= 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 o= ur > array of arrays. Then I have the memory contents, with addresses on the > left, > and contents on the right. > > ------------------------------------- > > ($0) VARIABLE > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > DW_AT_location: 0x1000 > DW_AT_type: $1 > > ($1) ARRAY > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > subrange: lower_bound =3D 1, count =3D 4 > DW_AT_data_location: DW_OP_push_object_address; DW_OP_deref > DW_AT_type: $2 > > ($2) ARRAY > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > subrange: lower_bound =3D 1, count =3D 4 > DW_AT_data_location: DW_OP_push_object_address; DW_OP_deref > DW_AT_type: $3 > > ($3) INTEGER > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 reported the bug. --=20 You are receiving this mail because: You are on the CC list for the bug.=