From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10846 invoked by alias); 30 Dec 2006 15:06:58 -0000 Received: (qmail 10837 invoked by uid 22791); 30 Dec 2006 15:06:57 -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; Sat, 30 Dec 2006 15:06:53 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H0fnO-00041b-Ql; Sat, 30 Dec 2006 10:06:50 -0500 Date: Sat, 30 Dec 2006 15:06:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: MI: Another -var-update bug? [PATCH] Message-ID: <20061230150650.GB15107@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17790.36044.454650.114329@kahikatea.snap.net.nz> <17791.40309.90872.126841@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17791.40309.90872.126841@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00358.txt.bz2 On Wed, Dec 13, 2006 at 07:28:05PM +1300, Nick Roberts wrote: > > Variable objects appear to test scope on a frame basis (in c_value_of root). > > If we create a variable object for j in the inner block of the program below > > then doing -var-update on line 10 doesn't report it as being out of scope. > > But struct varobj_root has a member struct block *valid_block. Presumably > > the addresses in this structure can be used to test if the variable is still > > in scope or not > > Something like below? Yeah. My only concern about this is a variable going out of scope which might then come back into scope. That can't happen if the frame is gone (unless something has changed), but it can happen with blocks once we support optimized blocks better (I posted a patch for this once). Here's an example. Suppose we have this code: int func() { int i = foo(); { int j = bar(); j = j * j; i += j; } baz(); return i; } Since baz can't see i or j, it's legitimate for the compiler to move the call to baz up to right after the call to bar. Then we'll appear to "leave" the block and "re-enter" it after another step. Will the front end delete the varobj if it sees in_scope="false"? -- Daniel Jacobowitz CodeSourcery