From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27227 invoked by alias); 6 Jan 2007 11:24:59 -0000 Received: (qmail 27218 invoked by uid 22791); 6 Jan 2007 11:24:58 -0000 X-Spam-Check-By: sourceware.org Received: from heller.inter.net.il (HELO heller.inter.net.il) (192.114.186.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Jan 2007 11:24:52 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-195-26.inter.net.il [83.130.195.26]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id BLR97271 (AUTH halo1); Sat, 6 Jan 2007 13:24:44 +0200 (IST) Date: Sat, 06 Jan 2007 11:24:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: <200701061412.54562.ghost@cs.msu.su> (message from Vladimir Prus on Sat, 6 Jan 2007 14:12:54 +0300) Subject: Re: -var-list --locals proposal Reply-to: Eli Zaretskii References: <200701052303.59465.ghost@cs.msu.su> <200701061412.54562.ghost@cs.msu.su> X-IsSubscribed: yes 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/msg00104.txt.bz2 > 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. > > > 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. We could cater to XCode by providing a switch to do what it wants.