[lldb-dev] Forcing lldb to refresh process state

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Wed Aug 23 14:24:00 PDT 2017


> On Aug 23, 2017, at 1:37 PM, Vadim Chugunov <vadimcn at gmail.com> wrote:
> 
> 
> On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton <clayborg at gmail.com <mailto:clayborg at gmail.com>> wrote:
> This isn't a work around right? You should be triggering your reverse step or reverse continue using a "process reverse-continue" or "thread reverse-step" right? If you do this, everything will just work. There should be no way this happens automagically without user interaction. Am I missing something?
> 
> Wait a second... As far as I know, LLDB itself does not support reverse-debugging (unless I missed something in a major way).  So there is no "process reverse-continue" command, is there?
> 
> I am not talking about adding proper reverse-debugging to lldb.  All I want to do is to hack together a script that emulates "process reverse-continue" in cases when remote target happens to support it.   I'm sending commands directly to remote gdb via `process plugin packet send bs`, but that leaves lldb out of the loop because it does not analyze the response packet.

Not sure why we wouldn't add it? It would be easy. The default implementation would return an unsupported error, and the ProcessGDBRemote would just pass the packets down.

Anything that internally calls lldb_private::Process::Flush() should do the trick as long as it actually causes it to get called. So:

target modules add
target modules load
target symbols add

They flush the process state because if you add a module or symbols or move a module around in memory we need to redo all stack traces. So you will need to do one of these as a work around and the command must succeed. I would suggest using:

(lldb) target modules add ...

where ... is the path of a shared library or executable that isn't in your target.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170823/c3e6613c/attachment-0001.html>


More information about the lldb-dev mailing list