PTRACE_EVENT_SIGTRAP

[Roland McGrath]

This is used only in the UTRACE_SIGNAL_HANDLER case.  That means after
tracehook_signal_handler(), which is where a signal handler has just
been set up.

For reference, in old ptrace, tracehook_signal_handler() is:

	if (stepping)
		ptrace_notify(SIGTRAP);

This means that when PTRACE_SINGLE{STEP,BLOCK},signr was used to
deliver the handled signal, we stop there in ptrace_notify.  This is
in lieu of a proper single-step trap, with the theory that what you
meant to "step to" next was the first instruction of the signal
handler, rather than the second instruction of the handler.

The only purpose of PTRACE_EVENT_SIGTRAP is to distinguish this case
from PTRACE_EVENT_SIGNAL as it would be for a real SIGTRAP after a
normal instruction step.  The only purposes of this distinction are to
make PTRACE_SETSIGINFO have no effect, and to make resumptions ignore
the data/signr argument.  The former makes it consistent with other
cases in utrace-ptrace that replace ptrace_notify() calls in the old
ptrace, but that itself is a known nit incompatibility with the old
behavior, so it's superfluous at best.  The latter is just intended
for pure bug-compatibility with the old behavior.  Aside from these,
there are no other reasons not to have the UTRACE_SIGNAL_HANDLER case
result in PTRACE_EVENT_SIGNAL, with siginfo_t filled in to match what
the old ptrace_notify() does.

Is that all correct?

In short, PTRACE_EVENT_SIGTRAP provides bug compatibility for
PTRACE_SINGLESTEP,signr silently acting like PTRACE_SINGLESTEP,0 when
called at the stop just provoked by the last PTRACE_SINGLESTEP,signr.
Is that it?

I think this is a piece of bug compatibility that upstream will be
happy to have "broken".  That is, I bet most people don't realize at
all PTRACE_SINGLESTEP,signr will sometimes swallow a signal after what
appears to be a normal single-step stop.  In fact, I suspect many
might say that this is worse than the previous behavior my addition of
this ptrace_notify() call (sometime before git so <2.6.12; Sep 2004,
not sure what version that was, maybe 2.6.9).  That behavior was that
PTRACE_SINGLESTEP,signr would stop at the second instruction of the
signal handler and never the first--but that would be a real step
(like you now get after PTRACE_SINGLESTEP,0 when stopped in
ptrace_notify() at the first instruction of the handler).  I'm quite
sure that at the time I never contemplated the signal-swallowing
implication of using ptrace_notify() here.

So, get rid of PTRACE_EVENT_SIGTRAP.  Instead for the case of 
UTRACE_SIGNAL_HANDLER when stepping, initialize *info to look
like a vanilla SIGTRAP and then fall into the default case for
real signals.

Does that all sound right to you, or did I miss something?


Thanks,
Roland