[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Proposal for ptrace improvements
    On Tue, Mar 1, 2011 at 4:24 PM, Tejun Heo <> wrote:
    > --------
    > P1. Always TASK_TRACED while ptraced
    > P2. Fix notifications to the real parent
    > P3. Keep ptrace resume separate from and beneath jctl stop
    > P5. "^Z" and "fg" for tracees

    Since this plan might get transformed into a file in Documentation/,
    I would like to chime in a few less important things we might want
    to clarify while we are at it.

    P6. Make PTRACE_GETSIGINFO useful for determining the type of ptrace stop.

    PTRACE_GETSIGINFO on real signal should return associated struct siginfo.

    PTRACE_GETSIGINFO on job control stops and process exits (WEXITED /
    WSIGNALED) should error out.

    What does PTRACE_GETSIGINFO return on various ptrace-generated
    Error? If not, what value is returned in siginfo->si_code?

    We have the following kinds of SIGTRAPs:

    * real SIGTRAP signal sent by breakpoint instruction
    * real SIGTRAP signal sent by other process
    * entering syscall (after PTRACE_SYSCALL)
    * exiting syscall (after PTRACE_SYSCALL)
    * after single step (after PTRACE_SINGLESTEP)
    * after execve (if PTRACE_O_TRACEEXEC opt is not on)
    * after execve (if PTRACE_O_TRACEEXEC opt is on)
    * in parent after fork (if PTRACE_O_TRACEFORK opt is on)
    * in parent after vfork (if PTRACE_O_TRACEVFORK opt is on)
    * in parent after clone (if PTRACE_O_TRACECLONE opt is on)
    * in child after vfork (if PTRACE_O_TRACEVFORKDONE opt is on)
    * before exit (if PTRACE_O_TRACEEXIT opt is on)

    Currently strace has to keep precise track on the alternating sequence
    of syscall enter/syscall exit stops. Which gets even trickier
    with extra magic SIGTRAP thrown in by execve and such.
    There were (and I suspect will be) hard to debug bugs when strace
    was getting out-of sync and printing garbage.

    Defining the PTRACE_GETSIGINFO's si_code so that each of these stops
    can be easily distinguished would be useful. I propose using values
    of SI_KERNEL + 1, SI_KERNEL + 2 etc, suitably #defined of course.

    We also have magic SIGSTOPs (magic in a sense they aren't
    real signals sent by other processes):
    * in child (if PTRACE_O_TRACE[V]FORK or PTRACE_O_TRACECLONE opt is on)

    For example, flagging PTRACE_ATTACH SIGSTOP so that it can be
    uniquely identified would solve some problems gdb is having with it.

    I propose to similarly do it by using unique si_code for each.


     \ /
      Last update: 2011-03-02 00:07    [W:0.023 / U:159.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site