From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 410 invoked by alias); 2 Jul 2013 13:37:23 -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 400 invoked by uid 89); 2 Jul 2013 13:37:23 -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 13:37:21 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r62DbIR4021441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Jul 2013 09:37:19 -0400 Received: from host2.jankratochvil.net (ovpn-116-40.ams2.redhat.com [10.36.116.40]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r62DbD4a017181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Jul 2013 09:37:15 -0400 Date: Tue, 02 Jul 2013 13:37:00 -0000 From: Jan Kratochvil To: "Agovic, Sanimir" Cc: "gdb@sourceware.org" , "Boell, Keven" Subject: Re: Variable Length Arrays (VLA) proposal Message-ID: <20130702133712.GA17311@host2.jankratochvil.net> References: <0377C58828D86C4588AEEC42FC3B85A7176288F9@IRSMSX105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0377C58828D86C4588AEEC42FC3B85A7176288F9@IRSMSX105.ger.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-07/txt/msg00006.txt.bz2 Hello, On Fri, 28 Jun 2013 15:01:25 +0200, Agovic, Sanimir wrote: > We've created three proposals, how VLA support can be added to FSF GDB. FYI this plan is dealing various ways only with item (1) of my "plan" plan: VLA (Variable Length Arrays) and Fortran dynamic types http://sourceware.org/ml/gdb/2012-11/msg00094.html While archer-jankratochvil-vla also only implemented the item (1) due to a bit unclear implementation of values/types one hits the other issues trying to implement the item (1). The items (2)..(7) were therefore proposals learned from (1) which GDB cleanups would make the item (1) implementation easier and less fragile. > (1) > Resolving check_typedef: [...] > calculating sizes and bounds the inferior memory is required. Thus the parameter > of most of the TYPE_* macros need to be changed from "struct type*" to > "struct value*", as "struct value*" contains the memory of the inferior as well > as "struct type*". I agree that is the difficult part of this proposal... > (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. When hooking to value_type() you then need yet another new kind of value_address(). archer-jankratochvil-vla uses its object_address_get_data() to convert value_raw_address (pointing to Fortran array descriptor) into another addresses pointing to the real array data. Maybe it was intended that value_raw_address() would be returning descriptor address vs. value_address() returning real data address. But these differences are not clear to me in GDB. This is why I was rather suggesting item (6) of my "plan" to clean this up first. This your proposal (2) avoids fixing the fragile check_typedef usage but I understand that is a different bug from the Fortran VLA-types bug. The archer-jankratochvil-vla differentiates "whatis" vs. "ptype" so that for dynamic types "whatis" still prints that the type is dynamic. This would not be possible with the value_type hook but sure that is not a problem: +gdb_test "whatis temp1" "type = char \\\[variable\\\]" "second: whatis temp1" +gdb_test "ptype temp1" "type = char \\\[78\\\]" "second: ptype temp1" The memory leakage of types currently exists even in archer-jankratochvil-vla. There is unmaintained #if 0-ed garbage collector in archer-jankratochvil-vla. Described in item (2) of my "plan". 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. > (3) > Split struct type: > > The idea behind this proposal is to reflect the difference of types (dynamic/ > static attributes) in the type system used in GDB. At the moment we consider the > following types: > > - struct type > - struct static_type > - struct dynamic type > - struct typedef_type This seems to me as an implementation variant of the proposal (1). The current inferior type system is horrible but I did not consider its refactorization meaningful before GDB starts to use C++; which currently does not seem to happen soon. Regards, Jan