Change utrace_reset() to do user_disable_single_step(). Alternatively
we could change ptrace layer, but I think this is not ptrace specific.
Yes, it's right to fix this in the utrace layer.
But I'm not sure that's the right place in the code to fix it.
The expectation is that either we'll
On 09/21, Roland McGrath wrote:
Change utrace_reset() to do user_disable_single_step(). Alternatively
we could change ptrace layer, but I think this is not ptrace specific.
Yes, it's right to fix this in the utrace layer.
But I'm not sure that's the right place in the code to fix it.
The
On 09/21, Roland McGrath wrote:
I was worried about the case when the TIF_SINGLESTEP tracee detaches
itself and escapes finish_resume_report()-user_disable_single_step(),
say, utrace_report_exec(). But probably we can ignore this.
No, I think that is indeed a problem. If no engine is
On 09/22, Oleg Nesterov wrote:
On 09/21, Roland McGrath wrote:
I was worried about the case when the TIF_SINGLESTEP tracee detaches
itself and escapes finish_resume_report()-user_disable_single_step(),
say, utrace_report_exec(). But probably we can ignore this.
No, I think that is
OK, so what should we do for now?
If we can't come to a straightforward answer for the general case
fairly quickly, then we can do the simple change to start with.
Without the multitracing utrace_resume()-user_disable_single_step()
fixes the problem. Otherwise we probably need
Changes: syscall stepping + minor cleanups.
Seems to work, more or less, but surely there are some bugs.
Honestly, I don't really know how do the right thing here.
Anyway, most probably this code will be changed. Like ptrace,
ugdb uses -report_syscall_exit() to synthesize a trap. Unlike
ptrace,
