On 17 March 2017 at 16:23, Ted Woodward <ted.woodw...@codeaurora.org> wrote:
> > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > Pavel Labath via lldb-dev > Sent: Friday, March 17, 2017 4:48 AM > > > On 16 March 2017 at 21:43, Kamil Rytarowski <n...@gmx.com> wrote: > >> I imagined a possible flow of ResumeAction calls like: > >> [Generic/Native framework knows upfront the image of threads within > >> debuggee] > >> - Resume Thread 2 (PT_RESUME) > >> - Suspend Thread 3 (PT_SUSPEND) > >> - Set single-step Thread 2 (PT_SETSTEP) > >> - Set single-step Thread 4 (PT_SETSTEP) > >> - Clear single-step Thread 5 (PT_CLEARSTEP) > >> - Resume & emit signal SIGIO (PT_CONTINUE) > >> > >> In other words: setting properties on threads and pushing the > >> PT_CONTINUE button at the end. > > > None of this is really NetBSD-specific, except the whole-process signal > at the end (which I am going to ignore for now). I mean, the implementation > of it is different, but there is no reason why someone would not want to > perform the same set of actions on Linux for instance. I think most of the > work here should be done on the client. Then, when the user issues the > final "continue", the client sends something like $vCont;s:2;s:4;c:5. Then > it's up to the server to figure out how execute these actions. On NetBSD it > would execute the operations you mention above, while on linux it would do > something like ptrace(PTRACE_SINGLESTEP, 2); ptrace(PTRACE_SINGLESTEP, 4); > ptrace(PTRACE_CONTINUE, 5); (linux lldb-server already supports this > actually, although you may have a hard time convincing the client to send a > packet like that). > > The big problem with this sequence is non-stop mode. To continue thread 5 > while threads 2 and 4 are stepping, and thread 3 is stopped is not legal > using all-stop mode. lldb only supports non-stop mode in the gdb-remote > communications layer; the guts of the debugger do not support it, and could > get very confused when threads 2 and 4 stop, but thread 5 is still running. > > I think these are actually two different concepts you are conflating here. The non-stop mode is about "what happens when an event happens on one thread" -- on all-stop we stop all threads (that happen to be running), in non-stop we only stop the affected thread. Lldb handles the first, but not the second. However, this is different from deciding which threads will get a chance to run in the first place. The sequence of commands we talked about above is probably not possible, but you can certainly choose to run only a subset of threads (e.g. with SBThread::Suspend), and this should work fine in current lldb.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev