Re: gdbstub initial code, v7

[Roland McGrath <roland@redhat.com>]

> 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