From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13757 invoked by alias); 14 Sep 2009 20:21:38 -0000 Received: (qmail 13659 invoked by uid 22791); 14 Sep 2009 20:21:37 -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 20:21:34 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id F419B3A003; Mon, 14 Sep 2009 13:21:32 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id E988ACD9EB; Mon, 14 Sep 2009 13:21:32 -0700 (PDT) Message-ID: <4AAEA5DE.10009@vmware.com> Date: Mon, 14 Sep 2009 20:21:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Marc Khouzam CC: 'Doug Evans' , "'gdb-patches@sourceware.org'" , 'Greg Law' , 'Pedro Alves' , 'Hui Zhu' Subject: Re: [patch] only update dcache after write succeeds References: <20090914191657.E32D6844C3@localhost> <4AAE98F1.3000501@vmware.com> In-Reply-To: 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/msg00452.txt.bz2 Marc Khouzam wrote: > > >> -----Original Message----- >> From: Michael Snyder [mailto:msnyder@vmware.com] >> Sent: Monday, September 14, 2009 3:27 PM >> To: Doug Evans >> Cc: gdb-patches@sourceware.org; Marc Khouzam; Greg Law; Pedro >> Alves; Hui Zhu >> Subject: Re: [patch] only update dcache after write succeeds >> >> Doug Evans wrote: >>> Hi. >>> >>> Marc, Greg: Can you see if this patch fixes things for you? >> Hey Doug, >> >> I tested this change, and it does indeed seem to fix the problem >> with target record -- but. ;-) >> >> Part of the reason that it works is that record_xfer_partial >> calls error() instead of returning -1. If I change it so that >> it returns -1, things get more complicated. > > Just a note that PRecord used to return -1 which caused memory > to be changed even when the query was answered with 'n'. > That is why Hui changed it to error() OK -- and now I see why it used to change the memory anyway. The caller (memory_xfer_partial) would call the target beneath. Makes me suspect that Doug's change is OK in general.