From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26479 invoked by alias); 21 Dec 2006 08:34:03 -0000 Received: (qmail 26464 invoked by uid 22791); 21 Dec 2006 08:34:00 -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; Thu, 21 Dec 2006 08:33:56 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1GxJN9-00079A-UM for gdb-patches@sources.redhat.com; Thu, 21 Dec 2006 11:33:53 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GxJN1-00078d-1H; Thu, 21 Dec 2006 11:33:43 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: variable objects and registers Date: Thu, 21 Dec 2006 08:34:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com References: <17782.41205.881283.845357@kahikatea.snap.net.nz> <200612210933.21644.ghost@cs.msu.su> <17802.15684.48367.885442@kahikatea.snap.net.nz> In-Reply-To: <17802.15684.48367.885442@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612211133.16281.ghost@cs.msu.su> 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/msg00283.txt.bz2 On Thursday 21 December 2006 10:52, Nick Roberts wrote: > > > 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? If you've left a function, then all variables in that function are really dead. If you have a variable in most-nested scope in a function (say inside loop), that variable can go in scope and go out of scope many times as you step though the function. When you leave a function, the frontend might want to completely remove its data structures. When leaving local scope, it might want to just show the relevant GUI item is "out of scope" -- gray perhaps. > > 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. The first point I'm making here is that MI is not in-process interface, so we need to minimize the amount of commands. I believe that to update local variables, frontend should emit *one* command, that would provide all the necessary information -- including new/deleted varobjs, in/out scope, and new values. - Volodya