> 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.
I'm not sure about this. > 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. Yes, I do think that's a problem. We want gdb to report back promptly. One possibility is to have report_quiesce notice its argument is UTRACE_EVENT(SYSCALL_ENTRY) and roll back to before the syscall. That is, it enables SYSCALL_ENTRY and SYSCALL_EXIT reporting, then its report_syscall_entry uses UTRACE_SIGNAL_ABORT, report_syscall_exit does syscall_set_return_value(-ERESTARTNOHAND, 0) and then returns UTRACE_INTERRUPT. Now, we'll reenter a UTRACE_SIGNAL_REPORT callback "before" the system call, and we can stop there without being in any sticky situation. Thanks, Roland