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