From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22638 invoked by alias); 6 Jan 2007 21:51:17 -0000 Received: (qmail 22630 invoked by uid 22791); 6 Jan 2007 21:51:16 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 06 Jan 2007 21:51:09 +0000 Received: from kahikatea.snap.net.nz (p202-124-124-232.snap.net.nz [202.124.124.232]) by viper.snap.net.nz (Postfix) with ESMTP id BB9B43D827F; Sun, 7 Jan 2007 10:51:05 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id E22414F6BE; Sun, 7 Jan 2007 10:51:04 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17824.6599.480753.426058@kahikatea.snap.net.nz> Date: Sat, 06 Jan 2007 21:51:00 -0000 To: Vladimir Prus Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: -var-list --locals proposal In-Reply-To: <200701061527.37603.ghost@cs.msu.su> References: <200701052303.59465.ghost@cs.msu.su> <200701061412.54562.ghost@cs.msu.su> <200701061527.37603.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.0.92.6 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/msg00108.txt.bz2 > > > 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. Perhaps we could use Apple's "-stack-list-locals --create-varobjs" which would minimise divergence, and "-var-list-registers" which is analogous to "-var-list-children". Also maybe "-var-list --locals" would share more code with the existing -stack-list-locals than with the proposed "-var-list --registers". > > > > > 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. I've not seen XCode but Insight only shows the variables that are in scope are displayed initially and others appear as they come into scope. Then as variables go out of scope they are greyed out. > > 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. All GDB has to do is: a) Report whether the variable is in scope when the variable object is created. b) Report when it comes into/goes out of scope (as already done). And the frontend developer can choose the behaviour. > > We could cater to XCode by providing a switch to do what it wants. Apple have their own version of GDB so there is no need for a switch. > 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. -- Nick http://www.inet.net.nz/~nickrob