From 29b090c057176684cd624e8d350d767f6f68d595 Mon Sep 17 00:00:00 2001 From: Doug Evans Date: Tue, 1 Sep 2009 18:48:58 +0000 Subject: [PATCH] * gdb.texinfo (Caching Data of Remote Targets): Add note on non-stop mode's affect on remote caching. --- gdb/doc/ChangeLog | 5 +++++ gdb/doc/gdb.texinfo | 10 ++++++++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog index 8831e0a..f23b507 100644 --- a/gdb/doc/ChangeLog +++ b/gdb/doc/ChangeLog @@ -1,3 +1,8 @@ +2009-09-01 Doug Evans + + * gdb.texinfo (Caching Data of Remote Targets): Add note on + non-stop mode's affect on remote caching. + 2009-08-31 Jacob Potter Doug Evans diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 0e9fd44..52ead12 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -8427,8 +8427,14 @@ performance, because it reduces the overhead of the remote protocol by bundling memory reads and writes into large chunks. Unfortunately, simply caching everything would lead to incorrect results, since @value{GDBN} does not necessarily know anything about volatile values, memory-mapped I/O -addresses, etc. Therefore, by default, @value{GDBN} only caches data -known to be on the stack. Other regions of memory can be explicitly marked +addresses, etc. Furthermore, in non-stop mode (@pxref{Non-Stop Mode}) +memory can be changed @emph{while} a gdb command is executing. +Therefore, by default, @value{GDBN} only caches data +known to be on the stack@footnote{In non-stop mode, it is moderately +rare for a running thread to modify the stack of a stopped thread +in a way that would interfere with a backtrace, and caching of +stack reads provides a significant speed up of remote backtraces.}. +Other regions of memory can be explicitly marked as cacheable; see @pxref{Memory Region Attributes}. @table @code -- 2.7.4