On 10/13, Roland McGrath wrote: > > > 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.
Ignoring the problems below, why? > > 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. Well, but this doesn't look friendly to other engines... And at first glance this looks a bit too hairy. And, this doesn't cover another case: gdb asks to stop the tracee when it is already stopped by another engine and sleeps in utrace_resume() path. So, I think ugdb should be changed so that "signal SIG" always works (without reporing this signal) even when the stopped tracee doesn't have the signal context. As for $_siginfo (qXfer:siginfo:read::), I do not know what ugdb should do. Probably it can just report the all-zeroes siginfo or report si_signo = SIGSTOP. Oleg.