lkml.org 
[lkml]   [2011]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Proposal for ptrace improvements
    Hi Tejun,

    I didn't read the whole thread yet... perhaps this was already
    discussed in more details. IOW, please ignore "I don't understand"
    parts, I'll ask the questions later.

    On 03/01, Tejun Heo wrote:
    >
    > I3. Not well-defined job control behaviors while traced
    >
    > In general, jctl behaviors while ptraced aren't well defined.

    I'd say it is not defined at all ;) And to me this is the root of
    all problems.

    So, many thanks for this RFC. This is the first time someone tries
    to define the rules.

    > * PTRACE_CONT and other requests which resume the tracee overrides, or
    > rather works below, jctl stop. If jctl stop takes place on the task
    > group a tracee belongs to, the tracee will eventually participate in
    > the group stop and its tracer will be notified; however, when
    > PTRACE_CONT or other resuming request is made, the tracee will
    > resume execution regardless of and without affecting the jctl stop.
    >
    > I don't know whether these are by design or just happened as
    > by-products of the evolution of task group implementation in the
    > kernel, but regardless, in my opinion, both rules are sound and
    > useful. They might not be immediately intuitive and the resulting
    > behavior might seem quirky but to me it seems to be one of those
    > things which looks awkward at first but is ultimately right in its
    > usefulness and relative simplicity.
    >
    > More importantly, it doesn't matter what I or, for that matter, anyone
    > else thinks about them. They're tightly ingrained into the
    > userland-visible behavior and actively exploited by the current users
    > - for example, dynamic evalution in tracee context in gdb(1).
    > Changing behaviors as fundamental as these would impact the current
    > applications and debugging behaviors expected by (human) users.

    OK. I have to agree. Lets forget the PTRACE_CONT-needs-SIGCONT idea.
    Nobody like it, including Jan (even if he didn't nack it explicitly).
    Forget.

    > PROPOSAL
    > --------
    >
    > P1. Always TASK_TRACED while ptraced

    OK.

    > P2. Fix notifications to the real parent
    >
    > This pleasantly proved to be the least contentious change to make.
    > The usual group stop / continued notifications should be propagated to
    > the real parent whether the children are ptraced or not.

    Agreed.

    > P3. Keep ptrace resume separate from and beneath jctl stop

    This is not exactly clear to me... Probably I understand what
    you mean, but I am not sure about details.

    > P4. PTRACE_SEIZE

    This is the new request. You know, I'd like to discuss the details
    later and separately. Actually, I think the user-space developers
    should participate and tell what they need. As for me, I certainly
    agree that SIGSTOP from PTRACE_ATTACH is very wrong, and it is very
    bad that gdb has to send SIGSTOP if it wants to stop the tracee.
    IOW, I agree that something like this is needed and useful. In
    particular,

    > In both cases, jctl state is unaffected.

    Agreed.

    > P5. "^Z" and "fg" for tracees
    >
    > 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.
    >
    > A better way to solve this is simply giving the tracer the capability
    > to listen for the end of jctl stop.

    Hmm. I don't understand what "the end of jctl stop" actually means.

    Since you are talking about WCONTINUED below, I guess it means that
    the process is not group-stopped any longer, say, SIGCONT comes.
    OK. If the tracer is notified about the end of jctl stop, it can
    resume the tracee if it wants. end-of-jctl-stop is per-process, but
    I guess the debugger will be notified per-thread. Looks reasonable
    to me.

    > 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.

    OK.

    > What state the tracee is in
    > can be determined by retriving siginfo using PTRACE_GETSIGINFO.

    I don't understand this this details right now... But I guess this
    doesn't matter right now.

    Either way, debugger should have the ability to know the tracee's
    state wrt group-stop. To oversimplify, it should know the state of
    SIGNAL_STOP_STOPPED bit. Correct?

    Oleg.



    \
     
     \ /
      Last update: 2011-03-03 18:45    [W:0.025 / U:61.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site