On 09/25, Roland McGrath wrote:
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.
And how we can implement this?
regs-ax is updated right after call
On 09/25, Oleg Nesterov wrote:
On 09/25, Roland McGrath wrote:
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.
And how we can implement this?
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.
And utrace-ptrace should be compatible here, yes?
As far as the sequence of stops that a ptracer observes, the general answer
is
On 09/23, Roland McGrath wrote:
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
On 09/22, Roland McGrath wrote:
I think the only cases where you can have a ptrace stop followed by
actually taking the ret_from_sys_call path are tracehook_report_clone stops
(i.e. the stop inside a clone/fork/vfork syscall). If you last used
PTRACE_CONT or whatever and then hit
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
On 09/23, Roland McGrath wrote:
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
The tracee stops and reports PTRACE_EVENT_FORK from do_notify_resume(),
after that syscall_trace_leave() can't (and must not) be called.
Oh, I see what you mean. That is all under your control from the utrace
API level. You can use a syscall-exit report first if you want to for
keeping track
