From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15002 invoked by alias); 9 Dec 2006 20:47:28 -0000 Received: (qmail 14993 invoked by uid 22791); 9 Dec 2006 20:47:28 -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, 09 Dec 2006 20:47:22 +0000 Received: from kahikatea.snap.net.nz (p202-124-120-4.snap.net.nz [202.124.120.4]) by viper.snap.net.nz (Postfix) with ESMTP id ED8353DA417; Sun, 10 Dec 2006 09:48:30 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 56207BE3F2; Sun, 10 Dec 2006 09:42:54 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17787.8140.925641.542454@kahikatea.snap.net.nz> Date: Sat, 09 Dec 2006 20:47:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI: -var-update bug In-Reply-To: <20061208202300.GA26172@nevyn.them.org> References: <17785.48689.501272.349814@kahikatea.snap.net.nz> <20061208194304.GA24699@nevyn.them.org> <17785.49735.481567.393065@kahikatea.snap.net.nz> <20061208200434.GA25405@nevyn.them.org> <17785.50551.255052.307043@kahikatea.snap.net.nz> <20061208202300.GA26172@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.91.14 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/msg00141.txt.bz2 > > > Randomisation isn't even the issue - I think that what you've got now > > > is simply an accident, and varobjs associated with a particular frame > > > should not become valid if a similar looking frame reappears later. > > > > OK that shows I've misunderstood. I thought it was looking for a frame > > to associate with it. > > If a varobj is associated with a particular frame, and that frame > leaves the stack, I think we should report in_scope="false". I'm > thinking that we should always report in_scope="false" after that > point... even if another frame that happens to have the same frame > ID appears later. That's why I thought randomisation was an issue: without it presumably when GDB stops at the same point (after restarting) for the second time, the frame looks the same as it did the first time. In this situation, the user might want to keep the variable object. Where the user creates a variable object, comes out of the frame and goes into the next, it might be best for the variable object to be out of scope. Does GDB check the procedure name is different in this case? (if it's the same procedure, the variable object could presumably stay in scope). > There seem to be a bunch of different ways a varobj can associate > with a frame; I guess we don't need to stop varobjs that have > use_current_frame or no valid_block? Do you mean use_selected_frame? -var-create - * fred (USE_CURRENT_FRAME) Usual case. Documented. -var-create - @ fred (USE_SELECTED_FRAME) Undocumented. I think the latter is evaluated in the frame where execution stops. > > > Right now we never delete varobjs automatically. We could preserve > > > that, but set a flag on the varobjs indicating they're permanently out > > > of scope? > > > > What value is a variable object that is permanently out of scope? > > Just in_scope="false". I mean "what worth/benefit". :-) -- Nick http://www.inet.net.nz/~nickrob