lkml.org 
[lkml]   [2011]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 11/11] ptrace: implement group stop notification for ptracer
    Hello, Denys.

    On Wed, May 11, 2011 at 12:37:34AM +0200, Denys Vlasenko wrote:
    > > When group stop state of a seized tracee changes, JOBCTL_TRAP_NOTIFY
    > > is set, which triggers INTERRUPT trap but is sticky until the next
    > > PTRACE_GETSIGINFO.
    >
    > Why INTERRUPT trap? For group stops, we already have perfectly working
    > way to detect such a stop.

    Debugger may continue tracee and put it in a different trap. In such
    cases, group stop may be initiated and lifted multiple times while a
    tracee is trapped. It's much nicer to have symmetric notifications in
    those cases.

    Also, we might end up adding more status flags to si_pt_flags and it's
    much better to be able to say "INTERRUPT becomes and stays pending
    until the next GETSIGINFO if any of these flags may have chagned" than
    "if XXX change from x to y, or YYY changes to x to y or y to x,
    ... blah blah".

    > Can we just add a "group cont" notification which looks like
    > a waitpid result with WIFCONTINUED(waitpid_status) == 1 to the tracer?

    Consider the following scenario.

    1. A syscall traced tracee enters group stop while returning from a
    syscall. Tracer is notified.

    2. SIGCONT generated. Tracee is woken up and wait state is generated.

    3. Tracee traps for syscall completion before tracer has chance to
    wait(2).

    4. Oops, continued wait state lost.

    Note that generation of another trap can't be used to determine end of
    group stop. It might already have been PTRACE_CONT'd.

    This happens because wait states don't queue and shows why edge (or
    instance) notifications are usually worse than level ones. Think
    about RT signals which are jokes.

    > > Re-trapping is used only for group stop and INTERRUPT traps. If
    > > tracer wants to get notified about group stop, it either leaves tracee
    > > in the initial group stop trap or puts it into INTERRUPT trap. When
    > > INTERRUPT trap is scheduled while tracee is already in a trap,
    >
    > Sane tracer has no need to do PTRACE_INTERRUPT on a tracee
    > which is already stopped (for whatever reason): it already knows
    > it's stopped, and why. PTRACE_INTERRUPT is useful to cleanly stop
    > _running_ tracees.

    1. User wants to continue stopped task to investigate.

    2. Investigation done, now the user wants to wait for the end of group
    stop which will happen externally.

    3. Regardless of the current trap tracee is in, debugger can schedule
    INTERRUPT and be sure that tracee will trap into INTERRUPT without
    returning to userland and that it will be notified of group stop
    state changes.

    According to you, the above use case is insane, which might be true
    but I don't really care. I still want to have gdb which knows how to
    do the above.

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2011-05-11 17:53    [W:4.101 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site