Re: gdbstub initial code, v8 && ptrace

[Roland McGrath <roland@redhat.com>]

> 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.

> But it needs to return UTRACE_SIGNAL_DELIVER?

That's what you return when you want the signal delivered.
When you are stopping the tracee to decide about the signal,
that's not what you want.

UTRACE_STOP | UTRACE_SIGNAL_IGN is correct to not deliver the signal right
now, and stop instead.  If you want to deliver the signal later, then
you'll resume with UTRACE_INTERRUPT to ensure you get back to report_signal
and that can fill in the details and return UTRACE_SIGNAL_DELIVER.

> 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.

> 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.


Thanks,
Roland