From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28765 invoked by alias); 11 Apr 2008 20:05:42 -0000 Received: (qmail 28754 invoked by uid 22791); 11 Apr 2008 20:05:41 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Apr 2008 20:05:16 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1JkPUi-0001nc-L6 for gdb-patches@sources.redhat.com; Sat, 12 Apr 2008 00:05:12 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.63) (envelope-from ) id 1JkPUi-0001nX-As; Sat, 12 Apr 2008 00:05:08 +0400 From: Vladimir Prus Subject: Re: -var-update @ To: gdb-patches@sources.redhat.com,Nick Roberts Date: Fri, 11 Apr 2008 22:01:00 -0000 References: <200803261754.10513.vladimir@codesourcery.com> <200804032209.53480.vladimir@codesourcery.com> <18421.14387.463657.822174@kahikatea.snap.net.nz> <200804041331.44206.vladimir@codesourcery.com> User-Agent: KNode/0.10.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-Id: 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/msg00225.txt.bz2 Vladimir Prus wrote: > 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. Nick, for avoidance of doubt -- are you planning to finish this patch in near future? If not, I'll pick it up. - Volodya