From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9641 invoked by alias); 14 Sep 2009 18:02:27 -0000 Received: (qmail 9563 invoked by uid 22791); 14 Sep 2009 18:02:27 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 18:02:23 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 7CED915005; Mon, 14 Sep 2009 11:02:22 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by jupiter.vmware.com (Postfix) with ESMTP id 6E5B3DC056; Mon, 14 Sep 2009 11:02:22 -0700 (PDT) Message-ID: <4AAE8492.6060503@vmware.com> Date: Mon, 14 Sep 2009 18:02:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: Marc Khouzam , "'gdb@sourceware.org'" , 'Greg Law' , 'Hui Zhu' , 'gdb-patches ml' Subject: Re: PRecord sets memory even when it says it did not References: <200909141849.57563.pedro@codesourcery.com> <200909141901.08651.pedro@codesourcery.com> In-Reply-To: <200909141901.08651.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00428.txt.bz2 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?