Messages in this thread | | | Date | Mon, 5 Sep 2011 19:44:20 +0200 | Subject | Re: RFC: PTRACE_SEIZE needs API cleanup? | From | "Indan Zupancic" <> |
| |
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
| |