From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15382 invoked by alias); 4 Aug 2013 19:02:10 -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 15372 invoked by uid 89); 4 Aug 2013 19:02:09 -0000 X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sun, 04 Aug 2013 19:02:08 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r74J20MN009759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Aug 2013 15:02:01 -0400 Received: from host2.jankratochvil.net (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r74J1uF8022995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 4 Aug 2013 15:01:59 -0400 Date: Sun, 04 Aug 2013 19:02:00 -0000 From: Jan Kratochvil To: "Agovic, Sanimir" Cc: "gdb@sourceware.org" , "Boell, Keven" Subject: Re: Variable Length Arrays (VLA) proposal Message-ID: <20130804190156.GA31353@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-08/txt/msg00005.txt.bz2 On Fri, 28 Jun 2013 15:01:25 +0200, Agovic, Sanimir wrote: > (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 > Serves as a base. Certain properties are exposed using function pointers > instead of raw attribute access e.g. length, bounds. > > - struct static_type > Reassembles the functionality of the current struct type. It is used for > types with statically values of attributes. > > - struct dynamic type > Allows to express the dynamic values of attributes. Computation of length > and bounds might be done lazily. > > - struct typedef_type > A simple proxy type. Calls to length and bounds are forwarded to the > underlying type. I think you would need also some: - struct opaque_type to resolve TYPE_IS_OPAQUE/TYPE_STUB/TYPE_TARGET_STUB types. > Proposal (3) will make the type system of GDB more flexible, as differentiating > between static and dynamic types. Also it will calculate dynamic attributes when > they will be requested by the caller. If you want to do the calculation any time when TYPE_ARRAY_UPPER_BOUND_VALUE is called then you do not have the object address available - where will you get it? The global pointer archer-jankratochvil-vla is using is really not acceptable. > An implementation details which is left out is whether one would implement it in > a OO style similar to breakpoint_ops. In part similar to breakpoint_ops but also similar to SYMBOL_IMPL - to save the 8 bytes of a pointer - as struct type (main_type) should be very small. Due to expansion of whole CUs (Compilation Units) together with CU interdependencies one gets tons of struct type (main_type) instances with C++ inferiors. > Also > extensions and future requirements could be better addressed by simply > refactoring struct members into function pointers. The check_type function could > be shortened, as function pointers will do the dynamic calculation work, I believe you are now talking more about full struct type/main_type rework, aren't you? It could be better to provide data definition samples. Personally I do not think it is worth to start the struct type/main_type rework in some pseudo-C++, before real C++ gets deployed. > and in future steps completely removed by adding a function peel(), which > would recursively peel of any typedefs. This change would be rather large > and would affect many areas of GDB, like proposal (1). I do not understand much this paragraph and I find it mostly off-topic here. Callers of check_typedef currently expect all the typedefs get stripped so I do not see who would be the callers for peel(). > The implementation of proposal (2) would be very isolated and simple, but will > leave the static attributes in struct type, which are actually dynamic. After all I find the (2) proposal the most one feasible, hooking into value_type() together with some cleanups like my-proposal (5) LA_VAL_PRINT->LA_VALUE_PRINT should make it working. > However, also this change will be large as lots of GDB code need to be > touched but it is the preferred proposal from our side. As I see we found disagreement whether to go the (2) or (3) way I have placed some question above which should clear it up what are your plans. Thanks, Jan