From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10627 invoked by alias); 14 Sep 2009 18:15:15 -0000 Received: (qmail 10280 invoked by uid 22791); 14 Sep 2009 18:15:11 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 18:15:05 +0000 Received: (qmail 28003 invoked from network); 14 Sep 2009 18:15:04 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Sep 2009 18:15:04 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: PRecord sets memory even when it says it did not Date: Mon, 14 Sep 2009 18:15:00 -0000 User-Agent: KMail/1.9.10 Cc: Marc Khouzam , "'gdb@sourceware.org'" , "'Greg Law'" , "'Hui Zhu'" , "'gdb-patches ml'" References: <200909141901.08651.pedro@codesourcery.com> <4AAE8492.6060503@vmware.com> In-Reply-To: <4AAE8492.6060503@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909141915.07943.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2009-09/txt/msg00431.txt.bz2 A Monday 14 September 2009 18:59:46, Michael Snyder escreveu: > Pedro Alves wrote: > > On Monday 14 September 2009 18:53:51, Marc Khouzam wrote: > >>> -----Original Message----- > >>> From: Pedro Alves [mailto:pedro@codesourcery.com] > >>> Sent: Monday, September 14, 2009 1:50 PM > >>> To: gdb@sourceware.org > >>> Cc: Greg Law; Hui Zhu; Marc Khouzam; Michael Snyder; gdb-patches ml > >>> Subject: Re: PRecord sets memory even when it says it did not > >>> > >>>> Could this be related to the caching changes that have happened > >>>> recently? i.e. does the cache get updated even though the > >>> underlying > >>>> poke operation failed? If so, this issue would seem to be > >>> wider than > >>>> just prec (and wider than reverse, too). > >>> If so, then there's an easy way to find out: try again with > >>> "set stack-cache off". > >>> > >> Yes, that seems to fix everything. > > > > Then I'd suspect either a bug dcache_xfer_memory, or a missing > > target_dcache_invalidate/dcache_invalidate call somewhere. > > I'm not too familiar with this dcache. > Is it up to the target to_xfer_memory method > to invalidate it before erroring out? No. dcache_xfer_memory tries to handle it itself already, with dcache_invalidate_line, but there's probably a bug over there, which should be easy to catch stepping through dcache_xfer_memory in the offending case. Note that it is dcache_xfer_memory that calls the target to_xfer_memory routine, not memory_xfer_partial. -- Pedro Alves