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 expectation is that either we'll get to finish_resume_report, > which calls user_*_step, or that utrace_control is resuming us > without any expectation of a report. For UTRACE_RESUME in that > case, utrace_control calls user_disable_single_step. So probably > the UTRACE_DETACH case there should just do it to.
Yes, initially I was going to change utrace_control(DETACH), and this certainly looks more clean. 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. Another concern was implicit detach, but thinking more I do not see why utrace_resume() is better. OK, I'll do some testing and resend right now. In UTRACE_DETACH case reset can be true but the tracee is running. But I don't think it makes sense to check target->exit_state == 0, correct? Oleg.
