> I’m not sure why Ramana is interested in it Basically http://lists.llvm.org/pipermail/lldb-dev/2017-June/012445.html is what I am trying to implement in lldb which has been discussed in little more details here http://lists.llvm.org/pipermail/lldb-dev/2017-September/012815.html.
On Thu, Mar 29, 2018 at 9:40 PM, Frédéric Riss <fr...@apple.com> wrote: > On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev < > lldb-dev@lists.llvm.org> 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. > > > If we work on this, that’s not the way we should approach breakpoints in > non-stop mode (and it’s not how GDB does it). I’m not sure why Ramana is > interested in it, but I think one of the main motivations to add it to GDB > was systems where stopping all some threads for even a small amount of time > would just break things. You want a way to step over breakpoints without > disrupting the other threads. > > Instead of removing the breakpoint, you can just teach the debugger to > execute the code that has been patched in a different context. You can > either move the code someplace else and execute it there or emulate it. > Sometimes you’ll need to patch it if it is PC-relative. IIRC, GDB calls > this displaced stepping. It’s relatively simple and works great. > > I’ve been interested in displaced stepping for different reasons. If we > had that capability, it would become much easier to patch code. I’d love to > use this to have breakpoint conditions injected and evaluated without round > tripping to the debugger when the condition returns false. > > Fred > > 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 > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
