[lkml]   [2011]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Proposal for ptrace improvements

    On Tue, March 1, 2011 19:34, Tejun Heo wrote:
    > Maybe it should, maybe not, but that's mostly irrelevant because the
    > described behavior is the current behavior. There is no
    > continue-if-not-job-control-stopped operation and we shouldn't change
    > that beneath gdb because otherwise not only the behavior changes
    > unexpectedly but also the user doesn't have a way to resume the tracee
    > from within gdb. The user has to go to another terminal and send
    > SIGCONT explicitly. If gdb wants to improve the behavior, it sure can
    > implement proper job control behavior using the proposed changes.

    I'm not sure what Denys is talking about: Currently it's impossible to
    pass along SIGSTOP to traced processes. Quoting the ptrace manpage:

    Restarts the stopped child process. If data is nonzero and not
    SIGSTOP, it is interpreted as a signal to be delivered to the
    child; otherwise, no signal is delivered.

    So you can pass along signals, but it's ignored if it happens to be
    SIGSTOP. If you emulate SIGSTOP signals in the tracer by not calling
    PTRACE_CONT, SIGCONT on the task won't work because the task can't
    receive the signal until it's continued by the tracer, but the tracer
    doesn't get a new notification until it resumes the task.

    As for distinguishing STOP signals from stopped childs: Just don't set
    the WUNTRACED flag in the tracer for waitpid.

    If you want SIGSTOP to work on a traced task, then you have to add a
    new PTRACE_SETOPTIONS option which enables the changed behaviour.
    E.g. PTRACE_O_SIGSTOP which does pass all signals, even SIGSTOP for
    PTRACE_CONT/SYSCALL/etc. Without something like this I don't see how
    you can make job control for traced tasks work.

    To me it seems clear that job ctl state should be managed independently
    of ptrace stopped state. I'm not sure how that fits in with your
    proposed changes, but my impression is that you make everything a lot
    simpler by separating traced stopping/continuing from SIGSTOP/SIGCONT
    job control. It's just not the same. A task stopped by a trace event
    shouldn't generate a STOP signal for it's parent, only for real SIGSTOPS.



     \ /
      Last update: 2011-03-02 06:09    [W:0.023 / U:10.752 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site