> Yes, but this has nothing to do with utrace-ptrace. If we last used
> PTRACE_CONT, the tracee stops in utrace_resume() path before return to
> the user-mode, syscall_trace_leave() can't be called.
If I follow what you mean, that is just the x86 bug (now fixed upstream).
> Both tests fail. The 1st one is clear, ptrace_report_clone() is not
> finished yet. But the 2nd test-case reveals the problem:
> PTRACE_SINGLESTEP works exactly as I expected, but I didn't know that
> PTRACE_SINGLESTEP shouldn't bypass the syscall-exit stop!
No, it's weirder than that. PTRACE_SINGLESTEP means that you are not
doing syscall tracing, since it's not PTRACE_SYSCALL. But the
behavior (implemented by TIF_SINGLESTEP on x86) of single-step is to
simulate a hardware trap after a system call completes, so that from
the userland perspective single-step over a syscall insn is like just
any other insn (albeit one with many strange side effects). So it's
not syscall exit tracing that fires as far as the semantics, it's a
"normal" single-step trap (i.e. pretends to be). It just so happens
that on x86 the implementation of this shares the assembly code paths
with syscall tracing, so the simulation happens in syscall_trace_leave:
/*
* If we are single-stepping, synthesize a trap to follow the
* system call instruction.
*/
if (test_thread_flag(TIF_SINGLESTEP) &&
tracehook_consider_fatal_signal(current, SIGTRAP))
send_sigtrap(current, regs, 0, TRAP_BRKPT);
It's a further oddity that you can single-step (or not) "into" the
system call and then get a ptrace stop "inside" it, that being for
PTRACE_EVENT_FORK et al. From there, the thread register state shows
it being after the syscall insn, but (in vanilla ptrace, and at the
time of report_clone callbacks at utrace level) without the return
value register having been written yet. So if you were
single-stepping, you want to PTRACE_SINGLESTEP from there and still
have it stop right after the syscall rather than one insn later. The
debugger would not show the user the thread state at report_clone time
(i.e. PTRACE_EVENT_CLONE in vanilla ptrace) but just do its attaching
and bookkeeping and then repeat PTRACE_SINGLESTEP to see the state
after the completion of the one insn that happened to be the syscall insn.
Thanks,
Roland
