<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 23, 2017, at 1:37 PM, Vadim Chugunov <<a href="mailto:vadimcn@gmail.com" class="">vadimcn@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton <span dir="ltr" class=""><<a href="mailto:clayborg@gmail.com" target="_blank" class="">clayborg@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">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?</div></blockquote><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>Anything that internally calls lldb_private::Process::Flush() should do the trick as long as it actually causes it to get called. So:</div><div><br class=""></div><div>target modules add</div><div>target modules load</div><div>target symbols add</div><div><br class=""></div><div>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:</div><div><br class=""></div><div>(lldb) target modules add ...</div><div><br class=""></div><div>where ... is the path of a shared library or executable that isn't in your target.</div><div><br class=""></div><div><br class=""></div></body></html>