[lldb-dev] GDB RSPs non-stop mode capability in v5.0

[Greg Clayton via lldb-dev]

> On Apr 2, 2018, at 6:18 AM, Ramana <ramana.venkat83 at gmail.com> wrote:
> 
> 
> 
> On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton <clayborg at gmail.com <mailto:clayborg at gmail.com>> wrote:
> 
> 
>> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>> 
>> Hi,
>> 
>> It appears that the lldb-server, as of v5.0, did not implement the GDB RSPs non-stop mode (https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop <https://sourceware.org/gdb/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop>). Am I wrong?
>> 
>> If the support is actually not there, what needs to be changed to enable the same in lldb-server?
> 
> 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.
> 
> 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?

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.

> 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?

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.

>> 
>> 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?
> 
> 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. 
> 
> 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?

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.

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