### 10.20 Caching Data of Remote Targets

gdb caches data exchanged between the debugger and a remote target (see Remote Debugging). Such caching generally improves 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 gdb does not necessarily know anything about volatile values, memory-mapped I/O addresses, etc. Furthermore, in non-stop mode (see Non-Stop Mode) memory can be changed while a gdb command is executing. Therefore, by default, gdb only caches data known to be on the stack1. Other regions of memory can be explicitly marked as cacheable; see see Memory Region Attributes.

`set remotecache on`
`set remotecache off`
  This option no longer does anything; it exists for compatibility with old scripts.

`show remotecache`
  Show the current state of the obsolete remotecache flag.

`set stack-cache on`
`set stack-cache off`
  Enable or disable caching of stack accesses. When `ON`, use caching. By default, this option is `ON`.

`show stack-cache`
  Show the current state of data caching for memory accesses.

`info dcache` [`line`]
  Print the information about the data cache performance. The information displayed includes the dcache width and depth, and for each cache line, its number, address, and how many times it was referenced. This command is useful for debugging the data cache operation.

  If a line number is specified, the contents of that line will be printed in hex.

`set dcache size` size
  Set maximum number of entries in dcache (dcache depth above).
`set dcache line-size` line-size
  Set number of bytes each dcache entry caches (dcache width above). Must be a power of 2.
`show dcache size`
  Show maximum number of dcache entries. See also info dcache.
`show dcache line-size`
  Show default size of dcache lines. See also info dcache.

#### Footnotes

[1] 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.