Messages in this thread | | | From | Denys Vlasenko <> | Date | Wed, 2 Mar 2011 00:16:23 +0100 | Subject | Re: [RFC] Proposal for ptrace improvements |
| |
On Tue, Mar 1, 2011 at 4:24 PM, Tejun Heo <tj@kernel.org> wrote: > PROPOSAL > -------- > ... > P5. "^Z" and "fg" for tracees > > A ptracer, as it currently stands and proposed here, has full control > over the execution state of its tracee. The tracer is notified > whenever the tracee stops and can always resume its execution; > however, there is one missing piece. > > As proposed, when a tracee enters jctl stop, it enters TASK_TRACED > from which emission of SIGCONT can't resume the tracee. This makes it > impossible for a tracer to become transparent with respect to jctl. > For example, after strace(1) is attached to a task, the task can be > ^Z'd but then can't be fg'd. > > One approach to this problem is somehow making it work implicitly from > the kernel - as in putting the tracee into TASK_STOPPED or somehow > handling TASK_TRACED for jctl stop differently; however, I think such > approach is cumbersome in both concept and implementation. Instead of > being able to say "while ptraced, a tracee's execution is fully under > the control of its tracer", subtle and fragile exceptions need to be > introduced. > > A better way to solve this is simply giving the tracer the capability > to listen for the end of jctl stop. That way, the problem is solved > in a manner which is consistent, may not be to everyone's liking but > nonetheless consistent, with the rest of ptrace. Execution state of > the tracee is always under the control of the tracer. The only thing > which changes is that the tracer now can find out when jctl stop ends, > which also could be an additional useful debugging feature. > > It would be most fitting to use wait(2) for delivery of this > notification. WCONTINUED is the obvious candidate but I think it is > better to use STOPPED notification because the task is not really > resumed. Only its mode of stop changes. What state the tracee is in > can be determined by retriving siginfo using PTRACE_GETSIGINFO. > > This also effectively makes the notification level-triggered instead > of edge-triggered, which is a big plus. No matter which state the > tracee is in, a jctl stopped notification is guaranteed to happen > after the lastest event and the tracer can always find out the latest > state with PTRACE_GETSIGINFO. > > Using stopped notification also makes the new addition harmless to the > existing users. It's just another stopped notification. Both > strace(1) and gdb(1) don't distinguish the signal delivery and jctl > stop notifications and react the same way by resuming the tracee > unconditionally. One more stopped notification on SIGCONT emission > doesn't change much.
Let's spell this out in detail. Please correct me if I misunderstood your proposal:
We have a stopped task under ptrace. (More precisely: debugger got a WSTOPPED notification via waitpid. Debugger decided to emulate the job control stop, therefore it keeps tracee stopped, therefore it just waits on waitpid without doing any PTRACE_CONTs).
Another task sends SIGCONT to the tracee.
Debugger gets waitpid notification of the WSTOPPED, WSTOPSIG == SIGCONT form.
Debugger can check PTRACE_GETSIGINFO, which succeeds. Debugger now knows it's a signal delivery notification. (This step looks optional, since currently WSTOPPED, WSTOPSIG == SIGCONT combination is only possible on signal delivery, unlike, for example, WSTOPPED, WSTOPSIG == SIGSTOP, which is ambiguous).
Debugger performs PTRACE_CONT(SIGCONT) - it injects the signal. [Question: what if debugger doesn't? IOW: is it possible for debugger to suppress SIGCONTs, or not? IOW2: what should happen if debugger (a) does not do any PTRACE_CONT at all? or (b) does PTRACE_CONT(<other_sig>)? or (c) does PTRACE_CONT(0)? ]
Debugger gets WCONTINUED waitpid notification. [question: do we need this?]
-- vda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |