From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18726 invoked by alias); 16 Jan 2007 07:01:21 -0000 Received: (qmail 18707 invoked by uid 22791); 16 Jan 2007 07:01:19 -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 07:01:11 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H6iJb-0002vX-6r for gdb@sources.redhat.com; Tue, 16 Jan 2007 10:01:08 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1H6iJI-0002vE-Oo; Tue, 16 Jan 2007 10:00:45 +0300 From: Vladimir Prus Subject: Re: -var-list --locals proposal To: Daniel Jacobowitz , gdb@sources.redhat.com Date: Tue, 16 Jan 2007 07:01:00 -0000 References: <200701052303.59465.ghost@cs.msu.su> <20070110033841.GB14719@nevyn.them.org> 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/msg00254.txt.bz2 Daniel Jacobowitz wrote: > 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". I think it would be good to reuse varobj accross the frames. So, if you're in some function and look at its locals and then enter another function and try to look at parents variables you get the same varobjs. I don't think that creation of varobj is so expensive in gdb itself -- but for frontend it's more convenient to always have the same varobj associated with a variable. >> 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. --all-locals is fine with me. >> 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 :-) :-) - Volodya