From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9752 invoked by alias); 20 Sep 2009 06:18:34 -0000 Received: (qmail 9742 invoked by uid 22791); 20 Sep 2009 06:18:33 -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; Sun, 20 Sep 2009 06:18:28 +0000 Received: (qmail 5019 invoked from network); 20 Sep 2009 06:18:26 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Sep 2009 06:18:26 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI] -stack-list-variables Date: Sun, 20 Sep 2009 06:18: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> <20090919224050.5DE89C164@totara> In-Reply-To: <20090919224050.5DE89C164@totara> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909201018.36901.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/msg00640.txt.bz2 On Sunday 20 September 2009 Nick Roberts wrote: > > ...The new command is called -stack-list-variables, > > and it's checked in into CVS HEAD. > > I don't like this patch/commit for a couple of reasons. One reason I > proposed such a command was to move away from the loose syntax that MI > uses. In particular to move away from: > > > `LIST ==>' > ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )* "]" ' > > to > > `LIST ==>' > ` "[]" | "[" VALUE ( "," VALUE )* "]" ' > > > to provide a more JSON-like syntax. > > As with -stack-list-locals, the new output can give something like: > > -stack-list-variables --no-values > ^done,variables=[name="i",name="j",name="asdf",name="m",name="zxcv",name="qwert"] > > but to keep JSON-like syntax, this needs to be: > > -stack-list-variables --no-values > ^done,variables=[{name="i"},{name="j"},{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}] Well, with values printed, the output is: -stack-list-variables --thread 1 --frame 0 --all-values ^done,variables=[{name="x",value="11"},{name="s",value="{a = 1, b = 2}"}] and is therefore OK. It's no-values case that takes shortcuts. However, I plan a follow-up patch really soon now that will make -stack-list-variables output a block where each variable defined. As result, there will be two attributes for each variable, and the output above will be used in all cases, regardless of whether printing of values was requested. > which leads to my second point: > > Which `variables' are the arguments and which are locals? > Arguments might be a kind of local but they're not identical. > > How about the format below?: > > -stack-list-variables --no-values > ^done,variables={args=[{name="i"},{name="j"}], > locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]} Why would frontend care about which are locals and which are arguments? I don't think I saw any GUI than distinguish between those in variables view. 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? - Volodya