From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22972 invoked by alias); 14 Sep 2009 20:36:01 -0000 Received: (qmail 22941 invoked by uid 22791); 14 Sep 2009 20:36:00 -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 20:35:56 +0000 Received: (qmail 14242 invoked from network); 14 Sep 2009 20:35:55 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Sep 2009 20:35:55 -0000 From: Pedro Alves To: Doug Evans Subject: Re: PRecord sets memory even when it says it did not Date: Mon, 14 Sep 2009 20:36:00 -0000 User-Agent: KMail/1.9.10 Cc: Michael Snyder , Marc Khouzam , "gdb@sourceware.org" , Greg Law , Hui Zhu , "gdb-patches ml" References: <200909141936.10390.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909142135.58989.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/msg00455.txt.bz2 On Monday 14 September 2009 20:04:12, Doug Evans wrote: > It seems like what's needed is to move > > /* Make sure the cache gets updated no matter what - if we are > writing > to the stack, even if this write is not tagged as such, we still > need > to update the cache. */ > > if (inf != NULL > && readbuf == NULL > && !region->attrib.cache > && stack_cache_enabled_p > && object != TARGET_OBJECT_STACK_MEMORY) > { > dcache_update (target_dcache, memaddr, (void *) writebuf, reg_len); > } > > to after the call > > res = ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, NULL, > readbuf, writebuf, memaddr, reg_len); > > predicated on res > 0. > > [dcache.c does the write first, and then updates the cache if it > succeeded, we just need to do that here too, methinks] That's fine with me as well. There's one wrinkly corner case not being handled. If the to_xfer_partial routine throws an error, say a ptrace error of some kind (usually perror_with_name), the ops target may still have succeeded in writing a part of that partial transfer, but, the matching caches lines aren't being invalidated/committed. This is fine if we assume that errors are only thrown before attempting any transfer at all, but that is not reality. E.g., when xfering [1000, 2000) in a single go, that may fail half way, say, at 1500 with a hard thrown error. Only thing 100% safe to in these cases is to just flush the whole cache area that was attempted to be written, or perhaps simpler, the whole cache. Not something you'd see hapenning every day, but still something to consider at some point. -- Pedro Alves