Continuation of single stopped SBThread


i’m currently working on a debugger based on the public LLDB API and am currently looking into multi-threaded debugging. The debugger should support the following scenario:

  • user sets breakpoints
  • two or more threads get stopped due to breakpoints
  • user wants to continue execution of only one of the threads

SBThread has the methods Suspend/Resume. To my understanding (and tests), Suspend marks a thread as not to be continued when the entire process is continued. Which is the oposite of what i’d need for my use case.

I looked into the implementation of the command ‘thread continue’, but that uses the private LLDB API, which is sadly not an option for us at this point.

I’d be greatful for any hints.


From my experience, any command that can be used by the API can be invoked

problematically like this:

Oops… sent too soon :stuck_out_tongue:

I meant to write this:

lldb::SBCommandReturnObject ret;

m_debugger.GetCommandInterpreter().HandleCommand(“thread step-over”, ret);

Where m_debugger is the instance of SBDebugger


I must be missing something... Can't you just suspend all the other threads, and then continue?


Right now LLDB does something we term "process centric debugging". If any thread stops, then all threads and the process stops. This is required because of how software breakpoints are implemented. When we hit a software breakpoint, we stop all threads. When you want to continue we must do a:
1 - disable software breakpoint
2 - instruction single step thread that hit breakpoint on its own
3 - enable software breakpoint
4 - resume

If we don't stop other threads, they could easily miss the breakpoint if a thread is in state 2 above and other threads are left to run.

"thread centric debugging" is a long term goal, but has not been implemented yet. In order to do this we will require being able to evaluate an opcode by emulating the instruction itself and giving the emulator a read/write register and read/write memory callback. We currently have this with the (see lldb/include/lldb/Core/EmulateInstruction.h). The main problem is that we don't support emulating all the instructions for any architectures that we support. This would be the first step required in order to allow thread centric debugging (unless that is some really good hardware breakpoint support on your platform).

So right now, when any thread stops they all stop. When you resume, you have the option to suspend all other threads if you want to (we could easily add a SBThread::Resume() to implement this to make it easier. The main problem you run into there is deadlocks.

Greg Clayton

Totally missed that option, thanks for pointing it out!


Thanks for the detailed explanation! I guess i’ll try my luck with suspending other threads, emulating thread-centric debugging. We might luck out, our environment is very controlled. If that doesn’t work out we may have to live with process centric debugging for the time being.