This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Use data cache for stack accesses
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