From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12815 invoked by alias); 21 Dec 2006 06:34:03 -0000 Received: (qmail 12801 invoked by uid 22791); 21 Dec 2006 06:34:02 -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 06:33:58 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1GxHV4-0000vl-KA for gdb-patches@sources.redhat.com; Thu, 21 Dec 2006 09:33:55 +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 1GxHUy-0000vH-Kh; Thu, 21 Dec 2006 09:33:48 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: variable objects and registers Date: Thu, 21 Dec 2006 06:34:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com 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> In-Reply-To: <17801.58248.297377.752117@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: <200612210933.21644.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/msg00278.txt.bz2 On Thursday 21 December 2006 04:29, Nick Roberts wrote: > > > I think that we need more higher-level notification -- namely "new locals > > > appeared" and either: > > > - "varobj now refers to different object" > > > - or have a command that creates varobjs for all variables > > > in a function. > > > > The latter is "-stack-list-locals --make-varobjs" isn't it? Or are you > > talking about variables declared within compound statements? > > I see now that Insight has two commands: > > /* This implements the tcl command gdb_get_blocks > * > * Returns the start and end addresses for all blocks in > * the selected frame. > * > * Arguments: > * None > * Tcl Result: > * A list of all valid blocks in the selected_frame. > */ > static int > gdb_get_blocks (ClientData clientData, Tcl_Interp *interp, > int objc, Tcl_Obj *CONST objv[]) > > > and > > > /* This implements the tcl command gdb_block_vars. > * > * Returns all variables valid in the specified block. > * > * Arguments: > * The start and end addresses which identify the block. > * Tcl Result: > * All variables defined in the given block. > */ > static int > gdb_block_vars (ClientData clientData, Tcl_Interp *interp, > int objc, Tcl_Obj *CONST objv[]) > > > 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 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. - Volodya