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

Fri Mar 30 13:24:41 PDT 2018

You might not need non-stop mode to debug both the CPU and GPU. We did a similar thing, using lldb to debug an Android app and an app running on the Hexagon DSP under Linux. We didn’t use the same lldb, but that’s because Android Studio doesn’t know about Hexagon. The Android app was debugged with Android Studio’s lldb, and in Android Studio we opened a console window and ssh’d to Hexagon Linux, where we ran lldb (yes, Greg, lldb under Linux on the DSP!). We were able to debug the interaction between the CPU and DSP.

The reason I say you might not need non-stop mode is another DSP use case. On our proprietary DSP OS, the debug agent doesn’t stop all threads in a process when one thread stops. Even though lldb acts like all threads are stopped, only one stopped and the others are still running. As long as the stub doesn’t error out when lldb checks the other threads, lldb will behave correctly. If another thread hits a breakpoint while the current one is stopped, the stub waits until it gets a resume to send the stop-reply. So lldb thinks everything is stopped, but it’s not really.

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of Ramana via lldb-dev
Sent: Friday, March 30, 2018 12:29 PM
To: Frédéric Riss <friss at apple.com>
Cc: lldb-dev at lists.llvm.org
Subject: Re: [lldb-dev] GDB RSPs non-stop mode capability in v5.0

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

On Mar 29, 2018, at 7:32 AM, Greg Clayton via lldb-dev <lldb-dev at lists.llvm.org <mailto: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 <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). 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 <mailto: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 <mailto: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/0323345b/attachment.html>