Re: [RFA] Use data cache for stack accesses

[Pedro Alves <pedro@codesourcery.com>]

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  <jdpotter@google.com>
> 	    Doug Evans  <dje@google.com>
> (...)
> 
> 	* 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