From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6157 invoked by alias); 10 Jan 2007 03:38:49 -0000 Received: (qmail 6146 invoked by uid 22791); 10 Jan 2007 03:38:48 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 10 Jan 2007 03:38:44 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H4UIT-0003zJ-63; Tue, 09 Jan 2007 22:38:41 -0500 Date: Wed, 10 Jan 2007 03:38:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: -var-list --locals proposal Message-ID: <20070110033841.GB14719@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <200701052303.59465.ghost@cs.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701052303.59465.ghost@cs.msu.su> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00163.txt.bz2 On Fri, Jan 05, 2007 at 11:03:59PM +0300, Vladimir Prus wrote: > At the moment, to reliably show all locals, the frontend is forced to emit > -stack-list-locals on each step. To handle the case where a new variable > is in nested scope and has the same name as a variable in outer scope, > the frontend should compute addresses of all variables on each step, > and notice when they change. This is rather nasty. > > I propose to introduce a new command: > > -var-list --locals > > This command returns variable objects corresponding to every local > variable that is "live" at the current position in the program. If at all > possible, the command tries to return previously returned variable object. > > So, on each step, the frontend emits -var-list --locals and: > > 1. For all variable objects it never seen, create new GUI > elements. > 2. For all variable objects that were reported previously, > but are no longer reported, delete GUI elements. I think most of the complexity in this will come from reusing varobjs. Couldn't we do this with -var-update? The meaning of in_scope="false" is a bit unclear today, since we use it for anything whose value we can't find, and in optimized code a variable can go in and out of scope. So using that might not be a good idea. We could add another marker, though, such as frame_exited="true" to indicate that a varobj's associated frame has returned (or otherwise disappeared from the stack). A varobj would never transition from frame_exited="true" to frame_exited="false". > The question is what exactly can be considered "live" variables by > -var-list. 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. We could call this --all-locals; I think that "for the given frame" is implied. > Transition between those states can be reported via -var-update. The > differences between (1) and (3) is already reported via "in_scope" attribute. > I'm not sure if we need to expose the difference between (2) and (3), > and if so, if it's better to introduce another attribute -- "hidden" with > values "true" and "false", or new attribute "visibility", with values of: > > "yes" > "hidden" > "out_of_scope" C and C++ both call this "hidden"; GCC calls it shadowing (-Wshadow). You're right that this is just a detail. I'll try not to make my frequent mistake of focusing too much on the hardest and least useful case :-) -- Daniel Jacobowitz CodeSourcery