> On Apr 2, 2018, at 6:18 AM, Ramana <ramana.venka...@gmail.com> wrote:
>
>
>
> On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton <clayb...@gmail.com
> <mailto:clayb...@gmail.com>> wrote:
>
>
>> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <lldb-dev@lists.llvm.org
>> <mailto:lldb-dev@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
