Analysis of SINGLESTEP

[Denys Vlasenko]

On Tue, 2009-01-13 at 13:40 +0800, Wenji Huang wrote:
> Roland McGrath wrote:
> [...]
> > 
> > What's supposed to happen is that ptrace_resume uses ptrace_set_action to
> > store UTRACE_SINGLESTEP.  It then actually passes UTRACE_REPORT or
> > UTRACE_INTERRUPT to utrace_control (for the reasons explained in the
> > comments in the code for each of those cases).
> > 
> > The child should then get into either ptrace_report_quiesce or
> > ptrace_report_signal (ptrace_resumed case).  These both use
> > ptrace_resume_action to extract what was saved by ptrace_set_action, which
> > should still be UTRACE_SINGLESTEP.  Then whichever of these callbacks it is
> > should return that value, UTRACE_SINGLESTEP.  It's that return value that
> > is what should ensure that user_enable_single_step actually happens (in
> > utrace.c:finish_resume_report).
> > 
> > I'm not entirely sure I understood your description of what you see
> > happening.  But perhaps you can figure out exactly where it differs from
> > what I've described that I think it should do.
> > 
> > 
> > Thanks,
> > Roland
> > 
> Understood.
> The test step-simple can pass on 2.6.29-rc1+utrace(11 Jan). Seems the 
> regression has been fixed.

Yes. In my testing, latest Fedora kernels fixed ALL regressions
in utrace testsuite:

http://sourceware.org/systemtap/wiki/utrace/tests

(scroll down)

Fedora 9 (kernel 2.6.29-0.28.rc1.fc11.x86_64) x86_64:
    SKIP: erestart-debugger powerpc-altivec ppc-dabr-race step-to-breakpoint
        user-area-access user-area-padding x86_64-gsbase
    PASS: attach-into-signal attach-sigcont-wait attach-wait-on-stopped
        block-step clone-get-signal clone-multi-ptrace clone-ptrace
        detach-can-signal detach-parting-signal detach-stopped erestartsys
        event-exit-proc-environ event-exit-proc-maps
        late-ptrace-may-attach-check o_tracevfork o_tracevforkdone peekpokeusr
        ppc-ptrace-exec-full-regs ptrace-cont-sigstop-detach ptrace_event_clone
        ptrace-on-job-control-stopped reparent-zombie reparent-zombie-clone
        sa-resethand-on-cont-signal signal-loss step-into-handler step-jump-cont
        step-jump-cont-strict step-simple step-through-sigret
        stop-attach-then-wait syscall-reset tif-syscall-trace-after-detach
        tracer-lockup-on-sighandler-kill user-regs-peekpoke watchpoint
        x86_64-cs x86_64-ia32-gs
    Notes:
        Kernel is from rawhide (note f11 in its name).
        Many messages in kernel log, all like this:
        "WARNING: at kernel/ptrace.c:534 ptrace_report_signal+0x182/0x2a9()"
        Corresponding part of the source code:
        /*
         * We're resuming.  If there's no signal to deliver, just go.
         * If we were given a signal, deliver it now.
         */
        WARN_ON(task->last_siginfo != info);
        task->last_siginfo = NULL;
        if (!task->exit_code)
                return UTRACE_SIGNAL_REPORT | resume;


Not a single one in FAIL category.

Impressive. Thanks a lot Roland.
--
vda