Debugger memory watch/examine for cached memory

Question

I am trying to debug a program which is partially working with cached data memory and from cached instruction memory. The question is about how the debugger works, when trying to examine such a memory. Does it access the cached copy when examining a specific location? If so, does it actually modify the cache, as it has to fetch the data once it's a miss? Does it mean that the program behavior might be different under debugger from the one without it? Any way to debug cache-related issues, without the debugger to affect the caches?
Update: The specific CPU core is ARM Cortex-A5. The debugger is DSTREAM/DS-5

Answer 1

I think the question is a bit generic because it will depend on the CPU.

However some very global rules:

• The debugger will try to see what the CPU sees on a data access, which will include cache lookups on the data cache.
• This is different for instruction cache, as the debugger will normally not do a lookup as it will perform data accesses. But this is normally not a problem as instruction cache does not contain dirty data. Depending on the debugger, it can clean DCache and invalidate corresponding ICache line if a data is written.
• Debug access will try to not be intrusive, and can force a mode in which no linefill is performed in case of miss. But this is really dependent on the CPU and not a global rule.

Answer 2

The DS-5 uses a JTAG probe connected into the CPU. To read the CPU's addressable memory, it has to run the CPU through its micro-operations to fetch memory. This perturbs the cache differently than if the CPU were simply to run the program.

You can minimize the effect by not stopping the CPU until after critical (suspect) code and then try to piece together what must have happened from the contents of registers and memory. If you can run a program from its beginning to the breakpoint, especially if that is 10,000+ instructions, the cache probably will be put into the correct state. Unless there is asynchronous activity.

To identify whether an issue is due to caching, maybe you can simply disable the cache?