Improve handling of multiple successive continue packets in non-stop
mode. More specifically:
- Explicitly send error response (instead of crashing on assertion) if the user attempts to resume the same process twice. Since we do not support thread-level non-stop mode, one needs to always stop the process explicitly before resuming another thread set.
- Actually stop the process if "vCont;t" is delivered to a running process. Similarly, we only support stopping all the running threads simultaneously and return an error if the action would result in a subset of threads still running.
With this patch, running multiple processes simultaneously is still
unsupported. The patch also employs a hack to avoid enabling stdio
forwarding on "vCont;t" packet. Both of these issues will be addressed
by followup patches.
Sponsored by: The FreeBSD Foundation
I think this is going to be racy if new threads appear before we are able to stop everything. I mean that in the sense that if the client has listed all (known) threads of the process explicitly, and a new thread appears before we're able to act on it, then (I guess) the expected behavior would be to keep that thread running (but we won't do that).
Do we need to support this kind of stopping right now? Maybe we could only support the pid.-1 syntax for stopping all threads within a process? (which should also make the ResumeActionListStopsAllThreads logic simpler)