Re: RFC: PTRACE_SEIZE needs API cleanup?

["Indan Zupancic" <indan@nul.nu>]

On Mon, September 5, 2011 16:06, Denys Vlasenko wrote:
> In case you meant that "if we request group-stop notifications by using
> __WALL | WSTOPPED, and we get group-stop notification, and we do
> PTRACE_CONT, then task does not run (it sits in group-stop until SIGCONT
> or death)", then we have a problem: gdb can't use this interface, it
> needs to be able to restart the thread (only one thread, not all of
> them, so sending SIGCONT is not ok!) from the group-stop. Yes, it's
> weird, but it's the real requirement from gdb users.
[...]
> SIGCONT's side effect of waking up from group-stop can't be blocked.
> SIGCONT always wakes up all threads in thread group.
> Using SIGCONT to control tracee will race with SIGCONTs from other
> sources.
>
> This makes SIGCONT a too coarse instrument for the job.
[...]
> Yes... until gdb will want to give user a choice after SIGSTOP: continue
> to sit in group-stop until SIGCONT (wasn't possible until
> PTRACE_LISTEN), or continue executing (gdb's current behavior if user
> uses "continue" command). Therefore, gdb needs a way to do both.

Having thought a bit more about this, I think this is less of a problem
than it seems, because for a group stop we get a ptrace event for each
task, and this should be true for SIGCONT as well. So gdb could also
always let the group stop happen, and only when prompted to do so by
a user, continue one thread by sending SIGCONT and letting all the other
threads hang in trapped state. So the above choice doesn't have to be
given, it can be made explicitly by the user at SIGCONT time (continue
all threads, or just one).

Regards,

Indan