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 Wed, 23 Sep 2009 02:36:54 +0200, Roland McGrath wrote:
It would be worthwhile to cons a version of this test case that uses
PTRACE_SINGLESTEP instead of PTRACE_SYSCALL. I think your situation
is tickling the same issue, but we should have an empirical test.
[...]
I have a fix in hand that
On Wed, 23 Sep 2009 02:36:54 +0200, Roland McGrath wrote:
It would be worthwhile to cons a version of this test case that uses
PTRACE_SINGLESTEP instead of PTRACE_SYSCALL. I think your situation
is tickling the same issue, but we should have an empirical test.
[...]
I have a fix in hand
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
Thanks Roland.
But now I am even more confused...
I get that combination a lot! ;-)
Just to keep everyone confused, note that this thread now has approximately
nothing to do with single-step. It really does have something to do with
single-step, but only in the special sense of
Thanks Roland.
But now I am even more confused...
On 09/20, Roland McGrath wrote:
- PTRACE_SINGLESTEP does user_enable_single_step()
- when the tracee returns to user mode, the next instruction
causes exception, do_debug()-send_sigtrap() sends SIGTRAP
- the tracee
On 09/21, Oleg Nesterov wrote:
However,
int main(void)
{
assert(0 == prctl(666));
printf(after prctl\n);
return 0;
}
dies with Trace/breakpoint trap, dmesg says:
prctl: before=10246
prctl: after=10346
On 09/21, Oleg Nesterov wrote:
Yes, I modified the patch a bit (see below) to print the syscall number,
Forgot to attach the patch. I guess it is not really needed, but
just in case.
Oleg.
--- TTT/kernel/sys.c~TF_FBG 2009-06-17 14:11:26.0 +0200
+++ TTT/kernel/sys.c2009-09-21
Help! I spent all Sunday trying to do something with PTRACE_SINGLESTEP.
And I am totally confused, to the point I don't even know how/what to ask.
OK. Please forget about utrace. The tracee sleeps in, say, ptrace_signal()-
ptrace_stop() path. The tracer does ptrace(PTRACE_SINGLESTEP, data = 0).
- PTRACE_SINGLESTEP does user_enable_single_step()
- when the tracee returns to user mode, the next instruction
causes exception, do_debug()-send_sigtrap() sends SIGTRAP
- the tracee notices the signal and reports this SIGTRAP
Correct. But if the tracee is inside
16 matches
Mail list logo
