On 09/10, Roland McGrath wrote: > > > ugdb sets "please stop" flag and does utrace_control(INTERRUPT). However, > > in unlikely case the tracee can stop before ->report_signal() reporting > > I don't think this is the right thing to do. When the intent is explicitly > to interrupt, there is no reason to stop before the interruption is > complete, i.e. report_signal.
This means that ugdb_report_quiesce() should never return UTRACE_STOP, and that is all. But what about multitracing? Suppose that "(gdb) interrupt" happens just before, say, do_report_syscall_entry() and another engine wants to stop. If ugdb_report_quiesce() doesn't return UTRACE_STOP, then gdb will wait until another debugger resumes the tracee. What do you think? > If you only stop there, then you can always > process a signal injection with complete flexibility. Yes, sure (again, currently ugdb does not injection a signal even if the tracee was stopped in report_signal, but of course we can change this). Oleg.