> Be sure to speak with myself, Jim Ingham and Pavel in depth before undertaking this task as there will be many changes required.
Definitely. Thank you all for the responses. Will get back after digesting all the responses here. Regards, Ramana On Thu, Mar 29, 2018 at 8:02 PM, Greg Clayton <clayb...@gmail.com> wrote: > > > On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <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). 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. > > > 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. > > Be sure to speak with myself, Jim Ingham and Pavel in depth before > undertaking this task as there will be many changes required. > > Greg > > > Thanks, > Ramana > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev