From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16189 invoked by alias); 16 Jan 2007 06:57:21 -0000 Received: (qmail 16180 invoked by uid 22791); 16 Jan 2007 06:57:20 -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; Tue, 16 Jan 2007 06:57:16 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H6iFn-0002WT-MA for gdb@sources.redhat.com; Tue, 16 Jan 2007 09:57:12 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1H6iFe-0002WH-J3; Tue, 16 Jan 2007 09:56:58 +0300 From: Vladimir Prus Subject: Re: -var-list --locals proposal To: Nick Roberts , gdb@sources.redhat.com Date: Tue, 16 Jan 2007 06:57:00 -0000 References: <200701052303.59465.ghost@cs.msu.su> <17824.6599.480753.426058@kahikatea.snap.net.nz> User-Agent: KNode/0.10.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-Id: 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/msg00253.txt.bz2 Nick Roberts wrote: > > > > 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". Perhaps that's something we should discuss last. > > > > > > 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. I suppose this behaviour, if you consider it useful for your frontend, can be done by not creating any UI representation for a varobj until it comes into scope. > > > 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. So, -var-list --all-locals should create varobj for all locals in a function, and indicate which are in scope at the moment of creation? I think that's good. - Volodya