<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 2, 2018, at 6:18 AM, Ramana <<a href="mailto:ramana.venkat83@gmail.com" class="">ramana.venkat83@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:clayborg@gmail.com" target="_blank" class="">clayborg@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><br class=""><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="m_7377505087231338951Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">Hi,<br class=""><br class=""></div>It appears that the lldb-server, as of v5.0, did not implement the GDB RSPs non-stop mode (<a href="https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop" target="_blank" class="">https://sourceware.org/gdb/<wbr class="">onlinedocs/gdb/Remote-Non_<wbr class="">002dStop.html#Remote-Non_<wbr class="">002dStop</a>). Am I wrong?<br class=""><br class=""></div>If the support is actually not there, what needs to be changed to enable the same in lldb-server?<br class=""></div></div></div></div></div></div></blockquote><div class=""><br class=""></div></span>As Pavel said, adding support into lldb-server will be easy. Adding support to LLDB will be harder. One downside of enabling this mode will be a performance loss in the GDB remote packet transfer. Why? IIRC this mode requires a read thread where one thread is always reading packets and putting them into a packet buffer. Threads that want to send a packet an get a reply must not send the packet then use a condition variable + mutex to wait for the response. This threading overhead really slows down the packet transfers. Currently we have a mutex on the GDB remote communication where each thread that needs to send a packet will take the mutex and then send the packet and wait for the response on the same thread. I know the performance differences are large on MacOS, not sure how they are on other systems. If you do end up enabling this, please run the "process plugin packet speed-test" command which is available only when debugging with ProcessGDBRemote. It will send an receive various packets of various sizes and report speed statistics back to you.<span class=""></span></div></div></blockquote><div class=""><br class=""></div><div class="">So, in non-stop mode, though we can have threads running asynchronously (some running, some stopped), the GDB remote packet transfer will be synchronous i.e. will get queued? </div></div></div></blockquote><div><br class=""></div><div>In the normal mode there is no queueing which means we don't need a thread to read packets and deliver the right response to the right thread. With non-stop mode we will need a read thread IIRC. The extra threading overhead is costly.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">And this is because the packet responses should be matched appropriately as there typically will be a single connection to the remote target and hence this queueing cannot be avoided?<br class=""></div></div></div></blockquote><div><br class=""></div>It can't be avoided because you have to be ready to receive a thread stop packet at any time, even if no packets are being sent. With the normal protocol, you can only receive a stop packet in response to a continue packet. So there is never a time where you can't just sent the packet and receive the response on the same thread. With non-stop mode, there must be a thread for the stop reply packets for any thread that can stop at any time. Adding threads means ~10,000 cycles of thread synchronization code for each packet.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Menlo-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><br class=""></div>Also, in lldb at least I see some code relevant to non-stop mode, but is non-stop mode fully implemented in lldb or there is only partial support?<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div></span>Everything in LLDB right now assumes a process centric debugging model where when one thread stops all threads are stopped. There will be quite a large amount of changes needed for a thread centric model. The biggest issue I know about is breakpoints. Any time you need to step over a breakpoint, you must stop all threads, disable the breakpoint, single step the thread and re-enable the breakpoint, then start all threads again. So even the thread centric model would need to start and stop all threads many times. </div></div></blockquote><div class=""><br class=""></div><div class="">Greg, what if, while stepping over a breakpoint, the remaining threads can still continue and no need to disable the breakpoint? What else do I need to take care of?<br class=""></div></div></div></blockquote><div><br class=""></div>This is where we would really need the instruction emulation support for executing breakpoint opcodes out of place. I believe the other discussions have highlighted this need. Let me know if that isn't clear. That is really the only way this feature truly works.</div><div><br class=""></div><div>Greg</div></body></html>