From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27557 invoked by alias); 4 Apr 2008 09:32:12 -0000 Received: (qmail 27544 invoked by uid 22791); 4 Apr 2008 09:32:11 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 04 Apr 2008 09:31:54 +0000 Received: (qmail 10334 invoked from network); 4 Apr 2008 09:31:52 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Apr 2008 09:31:52 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: -var-update @ Date: Fri, 04 Apr 2008 11:45:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sources.redhat.com References: <200803261754.10513.vladimir@codesourcery.com> <200804032209.53480.vladimir@codesourcery.com> <18421.14387.463657.822174@kahikatea.snap.net.nz> In-Reply-To: <18421.14387.463657.822174@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: <200804041331.44206.vladimir@codesourcery.com> 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/msg00091.txt.bz2 On Friday 04 April 2008 00:04:03 Nick Roberts wrote: > 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. Well, if your patch fixes the issue that *you* saw, then it's already an improvement, and we better get it into the tree as soon as possible. - Volodya