lldb does not permit memory reads when target is running

Hi folks,

http://lldb.llvm.org/tutorial.html states:

The commands that currently work while running include interrupting the process to halt execution ("process interrupt"), getting the process status ("process status"), breakpoint setting and clearing (" breakpoint [set|clear|enable|disable|list] ..."), and memory reading and writing (" memory [read|write] ...").

However, I tried to read memory when my (embedded harvard arch) target is running:

(lldb) target list
Current targets:
* target #0: /home/mg11/src/main/devtools/main/heracles/csrgdbserver/test/examples/simple/kalgsd5te.elf ( arch=unknown--linux, platform=host, pid=1, state=running )
(lldb) memory read 0x1000 --count 4
error: Process is running. Use 'process interrupt' to pause execution.

Does my observation reflect a documentation or coding bug?

Matthew Gardiner

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

Documentation bug indeed.

Brief history: we started with the ability to read/write memory while running a long time ago. We switched away from this after our IDE was trying to make too many memory requests while the process was running to avoid interruption issues. These issues would happen when quickly stepping a target and where a variable view was trying to display the variables asynchronously after each process stopped notification and it would still be trying to display variables from stop #10 after we had resumed for the single step. Also since we manually run expression by interpreting the IR, we can run into issues where an expression is modifying memory (usually due to data formatters or synthetic child providers again for the variable view) as the process is running, so we needed to outlaw memory reads/writes while the process is running to avoid race conditions with expressions and having these expressions possibly modify variables and memory after we have resumed.

Ok, thanks for the confirmation, Greg. In my company's current IDE I think that we can read memory whilst running, but our chips have a sophisticated memory map (loaded into the IDE) which permits "risky" areas being read whilst in that state. Still, I wouldn't be at all surprised if our existing system is quietly suffering similar races to the ones which you've just pointed out!


Greg Clayton wrote: