On 11/18, Roland McGrath wrote: > > > In any case, what is the rationality? > > The rationale is that if you see utrace_resume_action(action)==UTRACE_STOP > in your callback, then you know another engine asked for stop
Yes, but engine can't know if the next one is going to return UTRACE_STOP. > and you can > decide to return UTRACE_REPORT if you want to see the UTRACE_SYSCALL_RESUMED > notification after the other engine resumes. If you aren't delaying your > consideration of the event until the UTRACE_SYSCALL_RESUMED case because > you don't care, then you don't return UTRACE_REPORT and are not guaranteed > the second report. OK, thanks. But shouldn't utrace_report_syscall_entry() reset report->action = UTRACE_RESUME after do_report_syscall_entry()? If we stop, report->action remains UTRACE_STOP when we do the reporting loop. It is not clear to me why ptrace_report_syscall_entry() uses utrace_syscall_action() under "if (UTRACE_SYSCALL_RESUMED)". This looks a bit strange because it returns the "unconditional" UTRACE_SYSCALL_RUN below. IOW, if ptrace should obey to another engine's request to abort this syscall, the code should use utrace_syscall_action() consistently. OTOH, PTRACE_O_SYSEMU always aborts. Not sure I understand how different engines can be friendly to each other. In short: should we remove this utrace_syscall_action() or should we add another one instead? (I think the latter). Oleg.