From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1664 invoked by alias); 21 Sep 2009 07:39:30 -0000 Received: (qmail 1648 invoked by uid 22791); 21 Sep 2009 07:39:29 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Sep 2009 07:39:24 +0000 Received: (qmail 14161 invoked from network); 21 Sep 2009 07:39:22 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Sep 2009 07:39:22 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI] -stack-list-variables Date: Mon, 21 Sep 2009 07:39:00 -0000 User-Agent: KMail/1.11.90 (Linux/2.6.24-24-generic; KDE/4.2.90; i686; svn-979530; 2009-06-10) Cc: gdb-patches@sources.redhat.com References: <200909191412.37692.vladimir@codesourcery.com> <19127.10118.691154.313151@totara.tehura.co.nz> In-Reply-To: <19127.10118.691154.313151@totara.tehura.co.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909211139.21055.vladimir@codesourcery.com> 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 X-SW-Source: 2009-09/txt/msg00658.txt.bz2 On Monday 21 September 2009 Nick Roberts wrote: > > That's only the "origin" of the values. Inside the function, parameters and locals > > obey exactly the same rules. > > If you are trying to understand how a variable gets a value then you're interested > in the origin of that value. > > > > If the front end doesn't care, it can always group these together. > > > > I was saying that all frontends I know do not seem to care, therefore it > > does not seem like we should care. > > I don't really know what other frontends do but it appears useful to me. > > > > > Even > > > > if we decide this information is necessary, would it not be better to present it > > > > like this: > > > > > > > > ^done,variables=[{name="i", arg="1"},{name="asdf"}] > > > > > > > > as this format is more extensible in case some other frontend might need > > > > even more finer details? > > > > > > I don't see how this helps. Breaking locals and args down further would require > > > a new command for backward compatibilty reasons. > > > > Why? You can always add new field, e.g. > > > > ^done,variables=[{name="i", truly-magic-kind-of-symbol="1"},{name="asdf"}] > > Perhaps I misunderstood. I thought you mean't a third kind of local, whatever that might > be, but we could equally add a new field like this too: > > > ^done,variables={args=[{name="i", truly-magic-kind-of-symbol="1"},{name="j"}], > locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]} So, those general approaches are essentially equivalent in their expressive power? In which case, it seems reasonable to pick the approach that more directly correspond to what current frontends need, namely a flat list of variables. Should a frontend appear that will want to explicitly show args/locals distinctions, we can also add the necessary field. So, we're open for future extensibility, without immediately introducing syntax that no frontend might ever end up needed. - Volodya