From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32743 invoked by alias); 16 Jan 2007 07:18:55 -0000 Received: (qmail 32735 invoked by uid 22791); 16 Jan 2007 07:18:54 -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; Tue, 16 Jan 2007 07:18:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H6iaj-0004Gl-Sd; Tue, 16 Jan 2007 02:18:46 -0500 Date: Tue, 16 Jan 2007 07:18:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: -var-list --locals proposal Message-ID: <20070116071845.GA16388@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <200701052303.59465.ghost@cs.msu.su> <20070110033841.GB14719@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00255.txt.bz2 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. I think I saw something about frame events on gdb-patches but I'm not going to try to catch up on that list until the weekend, I think. -- Daniel Jacobowitz CodeSourcery