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 > On Sep 4, 2014, at 12:54 AM, Mario Zechner <badlogicga...@gmail.com> wrote: > > Hi, > > 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. > > Thanks, > Mario > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
