<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 March 2017 at 16:23, Ted Woodward <span dir="ltr"><<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
From: lldb-dev [mailto:<a href="mailto:lldb-dev-bounces@lists.llvm.org">lldb-dev-bounces@<wbr>lists.llvm.org</a>] On Behalf Of Pavel Labath via lldb-dev<br>
Sent: Friday, March 17, 2017 4:48 AM<br>
<span class=""><br>
> On 16 March 2017 at 21:43, Kamil Rytarowski <<a href="mailto:n54@gmx.com">n54@gmx.com</a>> wrote:<br>
</span><span class="">>> I imagined a possible flow of ResumeAction calls like:<br>
>> [Generic/Native framework knows upfront the image of threads within<br>
>> debuggee]<br>
>>  - Resume Thread 2 (PT_RESUME)<br>
>>  - Suspend Thread 3 (PT_SUSPEND)<br>
>>  - Set single-step Thread 2 (PT_SETSTEP)<br>
>>  - Set single-step Thread 4 (PT_SETSTEP)<br>
>>  - Clear single-step Thread 5 (PT_CLEARSTEP)<br>
>>  - Resume & emit signal SIGIO (PT_CONTINUE)<br>
>><br>
>> In other words: setting properties on threads and pushing the<br>
>> PT_CONTINUE button at the end.<br>
<br>
> 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).<br>
<br>
</span>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.<br>
<br></blockquote><div><br></div><div>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.</div></div></div></div>