From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18158 invoked by alias); 9 Feb 2015 23:37:17 -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 18115 invoked by uid 89); 9 Feb 2015 23:37:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f43.google.com Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 09 Feb 2015 23:37:15 +0000 Received: by mail-oi0-f43.google.com with SMTP id z81so25558575oif.2 for ; Mon, 09 Feb 2015 15:37:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k1+H1J+2xm4ikd3LlahOcVTGeKcD3bHLN1X6VwjCh80=; b=FQksNq6+h8sUPtkR9rSjsjD6o/8Vr+f2TRv3BT5n+IBD5K9dFf3pKDw2ExudrDw9Cp Ec2ir/AA1/+ewvKEl7E87ZeENEMiJeUli5IJV7H/f7pm0Faisbv0GaE9BMrECAWE2sk5 AdNeS8KDP1Y+eLBgXFN4DFzXKttlMpnZIoExO6qPKVx0Y9/eRZomPklBbYvS/DWL7KoR cSMLLSKAQRnuGbluXKTBrfZ8GWp25DHeK9QJYQuq43sqhng+51vY4HwYDuJt4lJAJgnu lqZD3vDBwUTPnxLp7GEVDEE4bAF2bqqPEgXvxdCQ6qRLkgEViJMS2bDdK2fIcwRkQca6 S0Zg== X-Gm-Message-State: ALoCoQl40pZtYk7D5F/xOnpS/S0scgRW3CwsxeTY8koGQFbv7bz8ixPzMPfY1iYhMhWtGyOO9tlo MIME-Version: 1.0 X-Received: by 10.182.148.98 with SMTP id tr2mr13736688obb.28.1423525033581; Mon, 09 Feb 2015 15:37:13 -0800 (PST) Received: by 10.182.222.98 with HTTP; Mon, 9 Feb 2015 15:37:13 -0800 (PST) In-Reply-To: <20150209065213.GA15579@adacore.com> References: <1421243390-24015-1-git-send-email-keven.boell@intel.com> <1421243390-24015-2-git-send-email-keven.boell@intel.com> <20150209065213.GA15579@adacore.com> Date: Mon, 09 Feb 2015 23:37:00 -0000 Message-ID: Subject: Re: [V4 01/18] vla: introduce allocated/associated flags From: Doug Evans To: Joel Brobecker Cc: Keven Boell , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00233.txt.bz2 On Sun, Feb 8, 2015 at 10:52 PM, Joel Brobecker wrote: > [Copying Doug, as I think Doug has experience in this area, and is > also dealing with the kind of giant programs where size of types > really make a big difference] Thanks! >> Fortran 90 provide types whose values may be dynamically >> allocated or associated with a variable under explicit >> program control. The purpose of this commit is to read >> allocated/associated DWARF tags and store them to the >> main_type. >> >> 2014-05-28 Keven Boell >> Sanimir Agovic >> >> * dwarf2read.c (set_die_type): Add reading of >> allocated/associated flags. >> * gdbtypes.h (struct main_type): Add allocated/ >> associated dwarf2_prop attributes. >> (TYPE_ALLOCATED_PROP): New macro. >> (TYPE_ASSOCIATED_PROP): New macro. >> (TYPE_NOT_ALLOCATED): New macro. >> (TYPE_NOT_ASSOCIATED): New macro. > > struct main_type is size-critical, so we simply cannot add > fields to it that only a very small minority of instances > will actually be using.. Yeah. Plus it can be really hard to get rid of them, especially as years go by and stuff gets built on top, so best be especially conservative when adding them. > To avoid the size increase, I propose that we turn... > > struct dynamic_prop *data_location; > > ... into a chained list of dynamic properties. To determine > which type of property each element in the list is, we'll need > to introduce an enumerated type to be used as discriminant. I don't know the details enough at the moment to help much here, but *some* extension of data_location does sound reasonable, and certainly ok from the standpoint of not growing main_type. :-) I can even imagine removing data_location from the main_type "base class" [see below]. But I'm not advocating that that needs to be done now or even soon. > So, I propose something like that: > > /* FIXME: Add comment. */ > > enum dynamic_prop_kind > { > /* FIXME: Document. */ > DYNAMIC_PROP_DATA_LOCATION, > /* FIXME: Document. */ > DYNAMIC_PROP_ALLOCATED, > /* FIXME: Document. */ > DYNAMIC_PROP_ASSOCIATED, > }; > > /* FIXME: Document. */ > > struct dynamic_prop_list > { > enum dynamic_prop_kind kind; > struct dynamic_prop *prop; > struct dynamic_prop_list *next; > }; > > ... then replace... > > struct dynamic_prop *data_location; > > ... into ... > > struct dynamic_prop_list *dyn_prop_list; > > ... and finally adjust the macros to go through the list instead of > accessing the data through the dedicated fields. Using a function > which does the search for a given kind will probably be useful. > > I think you might find it easier to do it in 2 stages (and therefore > two patches): > > 1. Convert the current "data_location" field to the list scheme; > 2. Then add the two new kinds of properties, which should then > be fairly straightforward. Now that vptr_fieldno is gone we've got more room in the bitfields section of struct main_type. I can imagine having a bit there that says that data_location lives just after the struct. We do similar things with other space-important types. And if data_location has iterators for read access then it'd be trivial to first check that bit. But again I'm not suggesting that needs to be done now (or even soon). I like the list-with-accessor-fns approach being proposed though because I suspect it would make removing data_location from struct main_type straightforward if/when there's a need for it. One can imagine, of course, that if it were easier to subclass in the language then such things would fall out naturally instead of needing such attention and hacks. There's another 8 bytes in main_type, type_specific, that could go away if the data being pointed to followed the "base class".