From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25336 invoked by alias); 5 Jan 2007 09:10:31 -0000 Received: (qmail 25328 invoked by uid 22791); 5 Jan 2007 09:10:30 -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 Jan 2007 09:10:26 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H2l5e-0007WT-IQ for gdb-patches@sources.redhat.com; Fri, 05 Jan 2007 12:10:23 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1H2l5W-0007Uk-BN; Fri, 05 Jan 2007 12:10:10 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: MI: Another -var-update bug? [PATCH] Date: Fri, 05 Jan 2007 09:10:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com References: <17790.36044.454650.114329@kahikatea.snap.net.nz> <17821.38113.889832.231159@kahikatea.snap.net.nz> In-Reply-To: <17821.38113.889832.231159@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701051210.09186.ghost@cs.msu.su> 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: 2007-01/txt/msg00178.txt.bz2 On Friday 05 January 2007 02:59, Nick Roberts wrote: > > 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. >=20 > I don't get this failure. I suppose you've got some different version of gcc. I'll take a look. > > > /* 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_bl= ock) || > > > ! =A0=A0=A0=A0=A0=A0 =A0 =A0 =A0pc >=3D BLOCK_END (var->root->valid_= block)) > > > ! =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); >=20 > Yes, it looks like the call to select_frame is not needed when the variab= le is > out of scope.=20=20 Good. Do we have a rule in place that small fixes to one's most recent comm= it that=20 seem obvious to you can be just committed? If yes, can you change this? > Daniel also suggested removing the call to reinit_frame_cache.=20 I think that would be great as a separate patch. - Volodya