From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-25081-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 25173 invoked by alias); 5 May 2006 06:25:58 -0000
Received: (qmail 25163 invoked by uid 22791); 5 May 2006 06:25:57 -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, 05 May 2006 06:25:55 +0000
Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) 	id 1Fbtl9-0005Gc-3J 	for gdb@sources.redhat.com; Fri, 05 May 2006 10:25:52 +0400
Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) 	by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) 	id 1Fbtks-00057f-JR; Fri, 05 May 2006 10:25:34 +0400
From: Vladimir Prus <ghost@cs.msu.su>
To: Daniel Jacobowitz <drow@false.org>
Subject: Re: -var-update and address changes
Date: Fri, 05 May 2006 06:25:00 -0000
User-Agent: KMail/1.7.2
Cc: Jim Ingham <jingham@apple.com>,  Nick Roberts <nickrob@snap.net.nz>,  gdb@sources.redhat.com
References: <e1iqcl$2k4$1@sea.gmane.org> <200605031002.21910.ghost@cs.msu.su> <20060504145046.GA32605@nevyn.them.org>
In-Reply-To: <20060504145046.GA32605@nevyn.them.org>
MIME-Version: 1.0
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200605051025.33901.ghost@cs.msu.su>
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2006-05/txt/msg00034.txt.bz2

On Thursday 04 May 2006 18:50, Daniel Jacobowitz wrote:
> On Wed, May 03, 2006 at 10:02:21AM +0400, Vladimir Prus wrote:
> > On Tuesday 02 May 2006 21:22, Jim Ingham wrote:
> > > Shouldn't the call to var->root->lang->value_of_root down at the
> > > bottom of value_of_root take care of fetching the new value?
> >
> > Well, it fetches the new value, I believe.
>
> For the wrong frame.
>
> I've only lightly tested this; could you give it a try?  If it works, I
> think we should really get the "@" syntax added to the manual and
> testsuite.
>
> The removed reinit_frame_cache is undoubtedly a performance suck.  I
> see no reason it should be necessary.  This code is still dubious;
> the select_frame call clobbers the selected frame and nothing ever
> restores it.

I believe that it's saved/restored in varobj_update.

- Volodya