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

[Ramana via lldb-dev]

> 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 <friss at apple.com> wrote:


> On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
>
>
> On Mar 29, 2018, at 2:08 AM, Ramana via lldb-dev <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). 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180330/1ab03de4/attachment.html>