<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 2 Apr 2018 at 16:28, Greg Clayton via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Apr 2, 2018, at 6:18 AM, Ramana <<a href="mailto:ramana.venkat83@gmail.com" target="_blank">ramana.venkat83@gmail.com</a>> wrote:</div><br class="m_6244365049695489249Apple-interchange-newline"><div><br class="m_6244365049695489249Apple-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"><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">On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton<span class="m_6244365049695489249Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>></span><span class="m_6244365049695489249Apple-converted-space"> </span>wrote:<br><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"><br><div><span><br><blockquote type="cite"><div>On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="m_6244365049695489249m_7377505087231338951Apple-interchange-newline"><div><div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></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">https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop</a>). Am I wrong?<br><br></div>If the support is actually not there, what needs to be changed to enable the same in lldb-server?<br></div></div></div></div></div></div></blockquote><div><br></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></span></div></div></blockquote><div><br></div><div>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></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><blockquote type="cite"><div><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"><div>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></div></div></div></blockquote><div><br></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></div></div></blockquote><div><br></div><div>I think this is one of the least important obstacles in tackling the non-stop feature, but since we're already discussing it, I just wanted to point out that there are many ways we can improve the performance here. The read thread *is* necessary, but only so that we can receieve asynchronous responses when we're not going any gdb-remote work. If we are already sending some packets, it is superfluous.</div><div><br></div><div>As one optimization, we could make sure that the read thread is disabled why we are sending a packet. E.g., the SendPacketAndWaitForResponse could do something like:</div><div>SendPacket(msg); // We can do this even while the read thread is doing work<br></div><div>SuspendReadThread(); // Should be cheap as it happens while the remote stub is processing our packet</div><div>GetResponse(); // Happens on the main thread, as before</div><div>ResumeReadThread(); // Fast.</div><div><br></div><div>We could even take this further and have some sort of a RAII object which disables the read thread at a higher level for when we want to be sending a bunch of packets.</div><div><br></div><div>Of course, this would need to be implemented with a steady hand and carefully tested, but the good news here is that the gdb-remote protocol is one of the better tested aspects of lldb, with many testing approaches available. </div><div><br></div><div>However, I think the place for this discussion is once we have something which is >90% functional..</div><div><br></div></div></div>