From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21622 invoked by alias); 9 May 2014 08:05:36 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21607 invoked by uid 89); 9 May 2014 08:05:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 May 2014 08:05:34 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 09 May 2014 01:00:32 -0700 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga001.jf.intel.com with ESMTP; 09 May 2014 01:05:30 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.70]) by IRSMSX104.ger.corp.intel.com ([169.254.5.98]) with mapi id 14.03.0123.003; Fri, 9 May 2014 09:05:29 +0100 From: "Agovic, Sanimir" To: 'Tom Tromey' CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH 2/2] handle VLA in a struct or union Date: Fri, 09 May 2014 08:05:00 -0000 Message-ID: <0377C58828D86C4588AEEC42FC3B85A71D86BED8@IRSMSX105.ger.corp.intel.com> References: <1399574816-12845-1-git-send-email-tromey@redhat.com> <1399574816-12845-3-git-send-email-tromey@redhat.com> In-Reply-To: <1399574816-12845-3-git-send-email-tromey@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00106.txt.bz2 > diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c > index 95b861e..59f354a 100644 > --- a/gdb/gdbtypes.c > +++ b/gdb/gdbtypes.c > @@ -1636,6 +1636,20 @@ is_dynamic_type (struct type *type) > return 1; > return is_dynamic_type (TYPE_TARGET_TYPE (type)); > } > + > + case TYPE_CODE_STRUCT: > + case TYPE_CODE_UNION: > + { > + int i; > + > + for (i =3D 0; i < TYPE_NFIELDS (type); ++i) > + if (!field_is_static (&TYPE_FIELD (type, i)) > + /* This can happen with Ada for reasons unknown. */ > + && TYPE_FIELD_TYPE (type, i) !=3D NULL > + && is_dynamic_type (TYPE_FIELD_TYPE (type, i))) > + return 1; > + } > + break; > } >=20 > return 0; > @@ -1753,6 +1767,86 @@ resolve_dynamic_type (struct type *type, CORE_ADDR= addr) > case TYPE_CODE_RANGE: > resolved_type =3D resolve_dynamic_range (type); > break; > + > + case TYPE_CODE_UNION: > As Joel has moved the heavy work out of the cases into separate function how about doing the same for arrays and unions (resolve_dynamic_compound)? > + { > + int i; > + unsigned int max_len; > + > + resolved_type =3D copy_type (type); > + TYPE_FIELDS (resolved_type) > + =3D TYPE_ALLOC (resolved_type, > + TYPE_NFIELDS (resolved_type) * sizeof (struct field)); > + memcpy (TYPE_FIELDS (resolved_type), > + TYPE_FIELDS (type), > + TYPE_NFIELDS (resolved_type) * sizeof (struct field)); > + for (i =3D 0; i < TYPE_NFIELDS (resolved_type); ++i) > + { > + struct type *t; > + > + if (field_is_static (&TYPE_FIELD (type, i))) > + continue; > + > + t =3D resolve_dynamic_type (TYPE_FIELD_TYPE (resolved_type, i), > + addr); > + > + TYPE_FIELD_TYPE (resolved_type, i) =3D t; > + if (TYPE_LENGTH (t) > max_len) > + max_len =3D TYPE_LENGTH (t); > + } > + > + TYPE_LENGTH (resolved_type) =3D max_len; > + } > + break; > + > + case TYPE_CODE_STRUCT: > + { > + int i; > + int vla_field =3D TYPE_NFIELDS (type) - 1; > + How about adding a gdb_assert to ensure NFIELDS is > 0. I know this cannot happen in this particular case but in others it might and one may assume that a struct has at least a member which is not the case. > diff --git a/gdb/testsuite/gdb.base/vla-datatypes.c b/gdb/testsuite/gdb.b= ase/vla- > datatypes.c > index 51e342e..8561a4e 100644 > --- a/gdb/testsuite/gdb.base/vla-datatypes.c > +++ b/gdb/testsuite/gdb.base/vla-datatypes.c > @@ -46,6 +46,18 @@ vla_factory (int n) > BAR bar_vla[n]; > int i; >=20 > + struct vla_struct > + { > + int something; > + int vla_field[n]; > + } vla_struct_object; > + > + union vla_union > + { > + int vla_field[n]; > + } vla_union_object; > + As you have pointed out the limitation of vla within arrays, this might as well serve as a test case that we deal with it. -Sanimir Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052