From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15635 invoked by alias); 30 Dec 2006 22:43:36 -0000 Received: (qmail 15625 invoked by uid 22791); 30 Dec 2006 22:43:35 -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; Sat, 30 Dec 2006 22:43:30 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-62.snap.net.nz [202.124.125.62]) by viper.snap.net.nz (Postfix) with ESMTP id EB80D3D817C; Sun, 31 Dec 2006 11:43:22 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 141D5BE449; Sun, 31 Dec 2006 11:38:47 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17814.60022.564828.19567@kahikatea.snap.net.nz> Date: Sat, 30 Dec 2006 22:43:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: MI: Another -var-update bug? [PATCH] In-Reply-To: <20061230150650.GB15107@nevyn.them.org> References: <17790.36044.454650.114329@kahikatea.snap.net.nz> <17791.40309.90872.126841@kahikatea.snap.net.nz> <20061230150650.GB15107@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.92.3 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/msg00378.txt.bz2 > 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), Currently variable objects consider a variable to be back in scope if a frame is re-entered. > 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. That sounds like some kind of optimisation. Does this happen with -O0? > Then we'll appear > to "leave" the block and "re-enter" it after another step. Entering another function doesn't take existing variables out of scope does it? Block addresses are measured against the PC of the frame that the variable is defined in. > Will the front end delete the varobj if it sees in_scope="false"? I can't speak for others but in Emacs I just use a grey font for variables that go out of scope and leave it to the user to explicily delete them. The worst scenario, if there is a problem at all, is that the watch expression would be inexplicably greyed for one step. -- Nick http://www.inet.net.nz/~nickrob