lkml.org 
[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2011-03-02 00:19    [W:4.163 / U:0.520 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site