From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-47013-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 28761 invoked by alias); 4 Jan 2007 23:59:43 -0000
Received: (qmail 28753 invoked by uid 22791); 4 Jan 2007 23:59:42 -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; Thu, 04 Jan 2007 23:59:37 +0000
Received: from kahikatea.snap.net.nz (p202-124-120-54.snap.net.nz [202.124.120.54]) 	by viper.snap.net.nz (Postfix) with ESMTP id B8A603D8352; 	Fri,  5 Jan 2007 12:59:33 +1300 (NZDT)
Received: by kahikatea.snap.net.nz (Postfix, from userid 500) 	id 1C9A34F6CD; Fri,  5 Jan 2007 12:59:31 +1300 (NZDT)
From: Nick Roberts <nickrob@snap.net.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <17821.38113.889832.231159@kahikatea.snap.net.nz>
Date: Thu, 04 Jan 2007 23:59:00 -0000
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: MI: Another -var-update bug? [PATCH]
In-Reply-To: <E1H2Xe8-0007Mc-Ae@zigzag.lvk.cs.msu.su>
References: <17790.36044.454650.114329@kahikatea.snap.net.nz> 	<17791.40309.90872.126841@kahikatea.snap.net.nz> 	<E1H2Xe8-0007Mc-Ae@zigzag.lvk.cs.msu.su>
X-Mailer: VM 7.19 under Emacs 22.0.92.5
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2007-01/txt/msg00162.txt.bz2

 > This patch introduces this for me:
 >=20
 >         FAIL: gdb.mi/mi-var-cp.exp: update RX (3)
 >=20
 > Do you get this failure to? If yes, can you please fix it?
 > If no, let me know and I'll investigate.

I don't get this failure.

 > > /* FIXME: select_frame could fail */
 > > ! =A0 =A0 =A0 if (fi)
 > > ! =A0=A0=A0=A0=A0=A0{
 > > ! =A0=A0=A0=A0=A0=A0 =A0CORE_ADDR pc =3D get_frame_pc (fi);
 > > ! =A0=A0=A0=A0=A0=A0 =A0if (pc < =A0BLOCK_START (var->root->valid_bloc=
k) ||
 > > ! =A0=A0=A0=A0=A0=A0 =A0 =A0 =A0pc >=3D BLOCK_END (var->root->valid_bl=
ock))
 > > ! =A0=A0=A0=A0=A0=A0 =A0 =A0within_scope =3D 0;
 > > ! =A0=A0=A0=A0=A0=A0 =A0select_frame (fi);
 > > ! =A0=A0=A0=A0=A0=A0}
 >=20
 > The code later in this function is only executed if "within_scope" is
 > true. Would it be better to call select_frame only if within_scope is
 > set to true, like this:
 >=20
 >          if (pc <  BLOCK_START (var->root->valid_block) ||
 >              pc >=3D BLOCK_END (var->root->valid_block))
 >           within_scope =3D 0;
 >         else
 >           select_frame (fi);

Yes, it looks like the call to select_frame is not needed when the variable=
 is
out of scope.  Daniel also suggested removing the call to reinit_frame_cach=
e.

--=20
Nick                                           http://www.inet.net.nz/~nick=
rob