> Simple example. The tracee stopped in syscall-entry. the tracer does > PTRACE_SINGLESTEP. With the recent changes in utrace-cleanup > utrace_control() doesn't set TIF_SINGLESTEP, and the tracee passes > syscall_trace_leave() without TIF_SINGLESTEP.
Ah, yes. Well, the point of the arch/tracehook tweaks was that the utrace layer has all the information and can decide what to do. > But I guess utrace_report_syscall_exit() can look at utrace->resume > and notice UTRACE_SINGLESTEP ? Yes. Unlike ptrace, at the utrace layer we can have both syscall-exit and single-step going on at the same time (even by unrelated engines). If some engine doesn't care about syscall-exit, it will still get report_quiesce there and should reassert UTRACE_SINGLESTEP with its return value. But that makes it a bit unclear whether a UTRACE_SINGLESTEP return from report_syscall_exit wants a fresh step after the next insn, or wants a synthetic trap immediately after the syscall insn. So I wonder if what might be right is to have utrace_report_syscall_exit look at ->resume before its reporting. If it's single/block-step it can synthesize the trap there, so the signal is queued before the syscall-exit report is made. Thanks, Roland
