From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22581 invoked by alias); 21 Sep 2009 07:13:28 -0000 Received: (qmail 22571 invoked by uid 22791); 21 Sep 2009 07:13:25 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Sep 2009 07:13:21 +0000 Received: from totara (126.61.255.123.dynamic.snap.net.nz [123.255.61.126]) by viper.snap.net.nz (Postfix) with ESMTP id 28D4F3DA2C8; Mon, 21 Sep 2009 19:13:14 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id C440CC166; Mon, 21 Sep 2009 19:13:12 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19127.10118.691154.313151@totara.tehura.co.nz> Date: Mon, 21 Sep 2009 07:13:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [MI] -stack-list-variables In-Reply-To: References: <200909191412.37692.vladimir@codesourcery.com> <19126.42750.144028.812936@totara.tehura.co.nz> From: nickrob@snap.net.nz (Nick Roberts) X-IsSubscribed: yes 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/msg00655.txt.bz2 > 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"}]} -- Nick http://www.inet.net.nz/~nickrob