From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8572 invoked by alias); 21 Dec 2006 07:57:25 -0000 Received: (qmail 8563 invoked by uid 22791); 21 Dec 2006 07:57:24 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 21 Dec 2006 07:57:18 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-15.snap.net.nz [202.124.125.15]) by viper.snap.net.nz (Postfix) with ESMTP id 9DCDC3D8252; Thu, 21 Dec 2006 20:58:45 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id AE36EBE3D3; Thu, 21 Dec 2006 20:52:37 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17802.15684.48367.885442@kahikatea.snap.net.nz> Date: Thu, 21 Dec 2006 07:57:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: variable objects and registers In-Reply-To: <200612210933.21644.ghost@cs.msu.su> References: <17782.41205.881283.845357@kahikatea.snap.net.nz> <17801.40268.835284.224413@kahikatea.snap.net.nz> <17801.58248.297377.752117@kahikatea.snap.net.nz> <200612210933.21644.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.0.92.1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00282.txt.bz2 > > gdb_block_vars only gets called if gdb_get_blocks finds a new block which > > then finds any variabes local to it. That way new variable objects can be > > added (and old ones deleted if a block has disappeared) while keeping > > the variable objects which are still in scope. I think we should implement > > these functions in MI (perhaps Apple already have). > > Again, I think we need more automated approach. Frontend should have a > single command that: > > 1. Reports which local variables are really dead now > 2. Creates and reports variable object for new locals > 3. Reports which varobjs are out of scope We don't seem to be finding much agreement, except that what I have described does 2 and 3, and I don't really understand the difference between 1 and 3 When would a variable belong to just one of those two groups? > For example: > > -var-update --locals > ^done,varobjs=[{name="v1",in_scope="false"....}{"name="v2",in_scope="true"....}] > created=[{name="v3"....], > gone-forever=[{name="v0"...}] > > > Apple creates varobjs for all variables in all blocks in a function, and use > "in_scope" to track their scope. That might be good approach too. IIRC, > you've posted a patch to consider block boundaries when computing > "in_scope"? That's exactly what's needed for this approach to work. Yes, I'm fairly sure that's what the above functions from Insight do. That wouldn't be a coincidence either because ChangeLog records show that Jim Ingham worked on Insight while at Cygnus. -- Nick http://www.inet.net.nz/~nickrob