> On Aug 23, 2017, at 1:37 PM, Vadim Chugunov <vadi...@gmail.com> wrote: > > > On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton <clayb...@gmail.com > <mailto:clayb...@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.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
