From: lldb-dev [mailto:lldb-dev-bounces@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 <n54%gmx.com@localhost> 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.