This is the mail archive of the
mailing list for the Archer project.
Re: gdbstub initial code, v8 && ptrace
On 09/10, Roland McGrath wrote:
> > I am a bit confused... OK, ugdb is wrong wrt multitracing.
> > UTRACE_SIGNAL_REPORT case shouldn't return "UTRACE_STOP | UTRACE_SIGNAL_IGN",
> > it should return "UTRACE_STOP | UTRACE_SIGNAL_REPORT" to keep report->result.
> No, UTRACE_SIGNAL_REPORT is not meant for a return value. Its only use is
> in the incoming argument to tell you that a given report_signal call is
> standing in for a report_quiesce(0) call.
Yes, that is why initially ugdb returned " | UTRACE_SIGNAL_IGN". But
you misunerstood my concerns (or me your reply ;)
But. Suppose we have to attached engines. The first engine gets
UTRACE_SIGNAL_REPORT and returns "UTRACE_STOP | UTRACE_SIGNAL_IGN".
> > But it needs to return UTRACE_SIGNAL_DELIVER?
> That's what you return when you want the signal delivered.
or yes, it returns UTRACE_SIGNAL_DELIVER after gdb does "signal XX".
Now. The second engine gets UTRACE_SIGNAL_DELIVER or UTRACE_SIGNAL_IGN,
That is why ugdb_signal_report(UTRACE_SIGNAL_REPORT) tries to return
UTRACE_STOP | utrace_signal_action(action) to not change report->result
(passed to the next tracee) inside the reporting loop.
The worst case is UTRACE_SIGNAL_HANDLER. Single-stepping should know
about this case. This means that any engine should always return
UTRACE_resume_action | UTRACE_SIGNAL_HANDLER.
Unless we are going to change utrace_get_signal().
> > Probably we can check orig_ka != NULL and treat orig_ka == NULL as
> > UTRACE_SIGNAL_REPORT. Hopefully this can't be confused with
> > UTRACE_SIGNAL_HANDLER.
> I'm not really sure what you mean here.
If ->report_signal(orig_ka) was calles with orig_ka == NULL, then,
whatever utrace_signal_action(action) we see, originally it was
either UTRACE_SIGNAL_HANDLER or UTRACE_SIGNAL_REPORT but another engine
returned, say, UTRACE_SIGNAL_DELIVER/UTRACE_SIGNAL_IGN to deliver/stop.
> > Not sure about UTRACE_SIGNAL_HOLD, but this is very unlikely race.
> You probably don't want to use that, but I'm not entirely sure. ptrace
> doesn't use it, and the signal interception model is pretty much the same.
Yes, agreed. But there is one corner case. Until we generalize
utrace_stop()->ptrace_notify_stop() hook, the tracee can be reported as
stopped to gdb, but before it actually stops it can recieve a signal.
The remote protocol doesn't allow to send TSIG after we alreay sent
T00 (at least this actually confuses gdb), and we can't just stop, the
tracee should report this signal to debugger.
So, currently ugdb stops but uses UTRACE_SIGNAL_HOLD to report this