[lldb-dev] LLDB/NetBSD extended set of tasks

[Pavel Labath via lldb-dev]

On 17 March 2017 at 16:23, Ted Woodward <ted.woodward at codeaurora.org> wrote:

>
>
> From: lldb-dev [mailto:lldb-dev-bounces at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170320/330baae5/attachment.html>