From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4156 invoked by alias); 2 Jul 2013 19:21:06 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 4129 invoked by uid 89); 2 Jul 2013 19:21:02 -0000 X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,TW_YP autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 02 Jul 2013 19:20:45 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r62JKgF8032499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Jul 2013 15:20:43 -0400 Received: from host2.jankratochvil.net (ovpn-116-40.ams2.redhat.com [10.36.116.40]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r62JKck1005060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Jul 2013 15:20:41 -0400 Date: Tue, 02 Jul 2013 19:21:00 -0000 From: Jan Kratochvil To: "Agovic, Sanimir" Cc: "gdb@sourceware.org" , "Boell, Keven" Subject: Re: Variable Length Arrays (VLA) proposal Message-ID: <20130702192037.GA21818@host2.jankratochvil.net> References: <0377C58828D86C4588AEEC42FC3B85A7176288F9@IRSMSX105.ger.corp.intel.com> <20130702133712.GA17311@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130702133712.GA17311@host2.jankratochvil.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-07/txt/msg00007.txt.bz2 On Tue, 02 Jul 2013 15:37:12 +0200, Jan Kratochvil wrote: > > (2) > > Type normalization: > > > > This proposal is similar to Jan's approach [1] in transforming dynamic values > > of attributes into static ones: > > > > 1) resolve all dynamic attributes > > 2) create a copy of the type and assign the resolved attributes from step 1) > > > > This proposal doesn't require to change check_typdef completely nor changing, > > the TYPE_* macros, which makes this solution very isolated and lean. > > Instead of hijacking check_typedef we hook into value_type() to normalize the > > type. Since inferior types depend on a context - namely an address - to be > > resolvable this seems a good place to hook into. In addition all expression > > evaluations are routed via parse_and_eval() which returns a value, which may be > > associated with an address. Also the TYPE_* macros in gdbtypes.h could be left > > as-is. As a side effect gdb is now constantly creating types during the > > normalization process and will increase the memory consumption constantly as > > well. To avoid this behavior a garbage collector would be needed, which frees > > the memory again when required. This could be done for example when GDB returns > > to its main loop. Nevertheless, such a garbage collector can result in a > > performance overhead, which is expected to be very small. > > I find this proposal interesting as hooking into value_type may be the right > spot where one still has the address for DW_OP_push_object_address and where > one can create appropriate static type. Current archer-jankratochvil-vla > really usually calls object_address_set() close to value_type() anyway. > This way one can avoid the difficulty of one global object address variable in > archer-jankratochvil-vla when dealing with multiple variables at once. > > Implementation may not be so simple as for example > dwarf2_evaluate_loc_desc_full case DWARF_VALUE_MEMORY sets value address > added with its element offset which is wrong when one deals with > DW_AT_push_object_address. In general in GDB there is value_address, > value_raw_address, value_embedded_offset and value_pointed_to_offset which may > the value address more difficult to get and set. [...] > One needs to be careful about item (1) of my "plan": val_print / c_val_print > / LA_VAL_PRINT passing address and type passed separately. But it may work. > Current archer-jankratochvil-vla has some hack for it in pascal_val_print; > FYI pascal (fpc) needs similar dynamic types for its strings. One issue is that value_type() returns even typedefs. But the dynamic types needing to be converted to static form may be hidden after the typedefs. That should be still easy. If you have TYPE_CODE_ARRAY -> TYPE_CODE_STRUCT -> -> one of the fields dynamic TYPE_CODE_ARRAY then you cannot make the inner TYPE_CODE_ARRAY static but LA_VAL_PRINT will access it without new value_type() as LA_VAL_PRINT already passes around separate type and separate address. You cannot make the inner TYPE_CODE_ARRAY static apparently because the type differs according to which outer TYPE_CODE_ARRAY element you access. This is why I was thinking getting rid of things like LA_VAL_PRINT (converting them to some form of LA_VALUE_PRINT, my item (5)) first may make the VLA task easier. Regards, Jan