From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13483 invoked by alias); 6 Jan 2007 12:28:43 -0000 Received: (qmail 13473 invoked by uid 22791); 6 Jan 2007 12:28:41 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Jan 2007 12:28:37 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H3Aez-0007BN-B5 for gdb@sources.redhat.com; Sat, 06 Jan 2007 15:28:34 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1H3Aeq-0007Am-CU; Sat, 06 Jan 2007 15:28:20 +0300 From: Vladimir Prus To: Eli Zaretskii Subject: Re: -var-list --locals proposal Date: Sat, 06 Jan 2007 12:28:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb@sources.redhat.com References: <200701052303.59465.ghost@cs.msu.su> <200701061412.54562.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701061527.37603.ghost@cs.msu.su> 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 X-SW-Source: 2007-01/txt/msg00105.txt.bz2 On Saturday 06 January 2007 14:24, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Sat, 6 Jan 2007 14:12:54 +0300 > > Cc: gdb@sources.redhat.com > > > > > > As you explain further, this will actually list all variables that are > > > visible in the current scope. So a better name for this command would > > > be something like "-var-list --scope FRAME" or "-var-list --frame FRAME". > > > > At the moment, the "KIND" option to -var-list is document as the kind of > > objects for which varobjs are creates. Say > > > > -var-list --registers ... > > > > creates varobjs for registers and > > > > -var-list --locals > > > > will create varobjs for locals. On the contrary, > > > > -var-list --frame > > > > would be somewhat inconsistent -- it does not create varobjs for frames. > > Then perhaps we shouldn't reuse -var-list for this, but instead create > a new command entirely. Or use: -var-list --all-locals-in-frame ? I don't want to introduce too many commands similar commands. > > > > I think that to avoid creating and destroying variable > > > > objects as we step though inner blocks, -var-list should construct > > > > varobjs for all variables in all blocks of a function. > > > > > > Won't lazy creation (on as needed basis) be a better strategy? > > > > It might be more efficient. However, different frontend have different ideas > > how to show local vars. I believe that XCode, for example, shows all > > locals as soon as you enter the function. Lazy creation would prevent such > > usage. > > We shouldn't punish all front-ends because of what one of them does. At this point, it's not clear if: 1. Any frontend would need any other behaviour. 2. What the performance overhead would be. > We could cater to XCode by providing a switch to do what it wants. I don't think we should introduce switches until a need for such switch is demonstrated by a frontend that uses the current gdb version and has some issue with that. - Volodya