From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16553 invoked by alias); 14 Sep 2009 18:01:11 -0000 Received: (qmail 16477 invoked by uid 22791); 14 Sep 2009 18:01:10 -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:01:06 +0000 Received: (qmail 19740 invoked from network); 14 Sep 2009 18:01:04 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Sep 2009 18:01:04 -0000 From: Pedro Alves To: Marc Khouzam Subject: Re: PRecord sets memory even when it says it did not Date: Mon, 14 Sep 2009 18:01:00 -0000 User-Agent: KMail/1.9.10 Cc: "'gdb@sourceware.org'" , "'Greg Law'" , "'Hui Zhu'" , "'Michael Snyder'" , "'gdb-patches ml'" References: <200909141849.57563.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909141901.08651.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/msg00427.txt.bz2 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. -- Pedro Alves