> In this case the tracee resumes and stops after syscall_trace_leave()
> to report PTRACE_EVENT_FORK, but since it passes syscall_trace_leave()
> with TIF_SINGLESTEP set the tracee gets the unwanted send_sigtrap().
>
> Note: of course, this is hack. I think this should be move to utrace
> layer. Unless we are going to call finish_resume_report(), finish_report()
> should look at report->action and clear TIF_SINGLESTEP when needed.
I thought we had just covered this before. TIF_SINGLESTEP is an arch
implementation detail and will never belong in either the ptrace layer or
the utrace layer. All of this is just to work around the x86-specific case
of the step state on return from tracehook_report_syscall_exit() producing
(or not producing) the synthetic single-step SIGTRAP.
I think the sequence of changes we'll want for this is something like:
1. (upstream) add arch hook(s) for single-step SIGTRAP siginfo_t + arch
fields (i.e. x86's thread.error_code + thread.trap_no).
2. (upstream) change tracehook_report_syscall_exit() to use force_sig_info
instead of ptrace_notify, use that arch hook
-> powerpc et al PTRACE_SINGLESTEP-over-syscall goes from
ptrace-swallows-signal to normal signal case
3. (upstream) implement that arch hook for at least powerpc
-> synthetic SIGTRAP gets si_* as a real step would, rather than 0
4. (upstream) implement that arch hook for x86
5. (upstream) change x86 syscall_trace_leave to pass flag
tracehook_report_syscall_exit(), not call send_sigtrap()
-> x86 PTRACE_SINGLESTEP from syscall-exit stop no longer fake-traps
without another insn, but takes a true step trap after next insn
-> compatible with powerpc et al behavior, makes more sense
6. profit
-> more consistent behavior upstream, simpler mandate for utrace-ptrace
Is there anything wrong with that?
Thanks,
Roland
