From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26753 invoked by alias); 12 Mar 2014 13:40:58 -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 26740 invoked by uid 89); 12 Mar 2014 13:40:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD 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; Wed, 12 Mar 2014 13:40:57 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 12 Mar 2014 06:36:12 -0700 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga001.jf.intel.com with ESMTP; 12 Mar 2014 06:40:09 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.62]) by IRSMSX103.ger.corp.intel.com ([169.254.3.84]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 13:40:08 +0000 From: "Agovic, Sanimir" To: 'Joel Brobecker' CC: "tromey@redhat.com" , "Boell, Keven" , "gdb-patches@sourceware.org" Subject: RE: [PATCH v5 09/15] vla: resolve dynamic bounds if value contents is a constant byte-sequence Date: Wed, 12 Mar 2014 13:40:00 -0000 Message-ID: <0377C58828D86C4588AEEC42FC3B85A71773415A@IRSMSX105.ger.corp.intel.com> References: <1391704056-25246-1-git-send-email-sanimir.agovic@intel.com> <1391704056-25246-10-git-send-email-sanimir.agovic@intel.com> <20140228170941.GB16479@adacore.com> In-Reply-To: <20140228170941.GB16479@adacore.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00291.txt.bz2 Thanks for your review. -Sanimir > Would you mind explaining this change a little more; perhaps using > some example code would help me understand why we want to resolve > dynamic types in this case (and also only in this case)? >=20 I added a test[1] for DW_AT_count attribute with the help of the=20 dwarf assembler. I used const_value to embed the actual array data into the debug information itself rather than having a location in the inferior. + DW_TAG_variable { + {name array} + {type :$array_label} + {const_value hello DW_FORM_block1} + } The test[1] initially failed because we ended up handling the case LOC_CONST_BYTES which does not use value_at & friends and simply copies the raw data into the value and thus the bounds never get resolved. case LOC_CONST_BYTES: + if (is_dynamic_type (type)) + /* Value is a constant byte-sequence and needs no memory access. */ + type =3D resolve_dynamic_type (type, /* Unused address. */ 0); v =3D allocate_value (type); In all other cases so far we call value_at (...) to construct a value and therefore get the correct type/bounds. [1] https://sourceware.org/ml/gdb-patches/2014-02/msg00100.html -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