From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17040 invoked by alias); 16 Jan 2007 16:20:40 -0000 Received: (qmail 17026 invoked by uid 22791); 16 Jan 2007 16:20:39 -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 16:20:33 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H6r2v-0003JX-Rq for gdb@sources.redhat.com; Tue, 16 Jan 2007 19:20:31 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1H6r2n-0003FI-4k; Tue, 16 Jan 2007 19:20:17 +0300 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: -var-list --locals proposal Date: Tue, 16 Jan 2007 16:20:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb@sources.redhat.com References: <200701052303.59465.ghost@cs.msu.su> <20070116071845.GA16388@nevyn.them.org> In-Reply-To: <20070116071845.GA16388@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701161920.17596.ghost@cs.msu.su> 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/msg00260.txt.bz2 On Tuesday 16 January 2007 10:18, Daniel Jacobowitz wrote: > On Tue, Jan 16, 2007 at 10:00:44AM +0300, Vladimir Prus wrote: > > > 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. > > But, if we can export frame IDs in some safe and useful way to the > frontend, we can avoid having to recreate them at all. The front > end would just know that they were the same, and not reissue -var-list. So, you either have frame_id->list_of_varobjs mapping in gdb, or in the frontend. I'm not sure which one is better. If this kept in a frontend, you'd also need notification "frame id XXX has died" so that the frontend can clean up its mapping. We'd need similar thing for function arguments, perhaps -- command like -var-list --arguments that would try hard to reuse varobjs and which command can be used to implement stack display. I'd much prefer to have this logic in gdb, because doing it in the frontend is not anyway simpler, I think. - Volodya