This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: gdbstub initial code, v7
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.