From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10698 invoked by alias); 3 Apr 2008 20:05:02 -0000 Received: (qmail 10643 invoked by uid 22791); 3 Apr 2008 20:05:01 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 20:04:21 +0000 Received: from kahikatea.snap.net.nz (92.30.255.123.static.snap.net.nz [123.255.30.92]) by viper.snap.net.nz (Postfix) with ESMTP id 239303D9FF5; Fri, 4 Apr 2008 09:04:18 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 158528FC6D; Fri, 4 Apr 2008 08:04:03 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18421.14387.463657.822174@kahikatea.snap.net.nz> Date: Thu, 03 Apr 2008 21:30:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: -var-update @ In-Reply-To: <200804032209.53480.vladimir@codesourcery.com> References: <200803261754.10513.vladimir@codesourcery.com> <200803290937.57101.vladimir@codesourcery.com> <18415.3808.504498.834488@kahikatea.snap.net.nz> <200804032209.53480.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.2.50.1 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: 2008-04/txt/msg00079.txt.bz2 Vladimir Prus writes: > On Sunday 30 March 2008 07:54:08 Nick Roberts wrote: > > > So, we still don't know why the current code does not work? I think > > > we still get to figure out, to make sure that whatever bug there is > > > does not affect other cases. > > > > My patch didn't do the right thing (it always marked a floating variable > > object as changed) but it's along the right lines. How about this one? > > This patch seem to go in the right direction. I'm somewhat surprised that > evaluating previous expression gets bogus value, as opposed to getting value > in the frame where varobj was originally created. Any ideas why is that? I've not tried to understand _exactly_ what value was being retrieved, but basically var->root->exp was obtained once from gdb_parse_exp_1 in varobj_create and this has symbol information in var->root->exp->elts[2]. Previously this would be the symbol information for the variable in the frame for which the variable object was created. At the same time var->value was being updated relative to the selected frame, which gave an incorrect address value in value->address. I guess a variable's numeric value on the stack is computed using both the frame address and an address in the symbol table and these were inconsistent. /* Update expression to new frame. */ tmp_exp = var->root->exp; var->root->exp = tmp_var->root->exp; tmp_var->root->exp = tmp_exp; Moving var->root->exp into tmp_var->root->exp just ensures that this memory gets freed when tmp_var is deleted: varobj_delete (tmp_var, NULL, 0); > Do you think you can write some test to go along this patch? We need some tests and documentation at some stage before the next release but perhaps Bogdan can confirm that this patch works for him first. -- Nick http://www.inet.net.nz/~nickrob