From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13422 invoked by alias); 29 Aug 2009 20:05:56 -0000 Received: (qmail 13414 invoked by uid 22791); 29 Aug 2009 20:05:55 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37,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; Sat, 29 Aug 2009 20:05:48 +0000 Received: (qmail 531 invoked from network); 29 Aug 2009 20:05:46 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Aug 2009 20:05:46 -0000 From: Pedro Alves To: Doug Evans Subject: Re: [RFA] Use data cache for stack accesses Date: Sat, 29 Aug 2009 20:25:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <7e6c8d660907081308r13bff580rdcf4822c77df8403@mail.gmail.com> <200908262108.49085.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: <200908292105.48831.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-08/txt/msg00545.txt.bz2 On Saturday 29 August 2009 01:55:30, Doug Evans wrote: > > dcache writes back lines in chunks. > > Actually, the dcache only writes to the target exactly what > target_xfer_partial would do. > Data point: For writes, if the line isn't already in cache, it is not > brought in. Oh, dcache_write_line has been deleted! I was looking at an older tree... Sorry about that. :-/ Great then! > > Do we still have rare border cases > > where the cache line can cover more than stack memory, hence > > still leading to incorrect results? > > Yeah, if, for example, .data abuts the stack in just the right way, > it'll get cached when "set stack-cache on". > Pretty rare that it would be a problem. Yeah. It would even be a rarer problem if we flushed the cache between high level operations in all-stop as well. In fact, with that, wouldn't we be safe to enable the dcache for all operations? > > Cache becoming stale in non-stop mode. > > The cache is now flushed between commands in non-stop mode. Thanks. I wonder how much performance we lose here, but I don't have one of those large apps to test handy ... :-) > + /* 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. */ EMISDBLSPC. ^ I'm fine with the patch now. Thanks. > 2009-08-28 Jacob Potter > Doug Evans > (...) > > * doc/gdb.texinfo (Caching Data of Remote Targets): Update text. > Mark `set/show remotecache' options as obsolete. > Document new `set/show stack-cache' option. > Update text for `info dcache'. Another convention is to put the ChangeLog path line like so: doc/ * gdb.texinfo (Caching Data of Remote Targets): Update text. Mark `set/show remotecache' options as obsolete. Document new `set/show stack-cache' option. Update text for `info dcache'. This has the advantange that you only have to remove that line when pasting the entry to the correct log file, instead of editing every possible changed-file entry, and it's clearer to everyone else where the log is supposed to go, IMHO. This is the convention we use at CS, FWIW. -- Pedro Alves