Purpose of TCB_SIGTRAPPED?

[Roland McGrath]

> Testing my SIGTRAP-handling patch further, I looked into
> this peculiar thing where strace does something
> (not really clear what) when process tries to mask or SIG_IGN
> SIGTRAP. (Noticed and quick-fixed a typo where we weren't
> printing SIG_IGN correctly, in cvs now).

This code predates my working on strace, and I had not looked at it before.
I understand the issue that motivated it, but I haven't tried to make sense
of the solution it attempts.

> Does anybody know/remember why this TCB_SIGTRAPPED trick is even needed?
> I want to document it in comments.

On modern kernels, there is no issue with setting SIGTRAP to SIG_DFL or
SIG_IGN.  It may once have been true in some Linux kernel version that
setting it to SIG_IGN wrongly caused early discard of SIGTRAP signals, but
for as long as I can recall knowing the relevant kernel code, it doesn't do
that when ptrace'd.

The issue that remains is when a thread blocks SIGTRAP (with sigsetmask et
al).  This does not affect syscall entry/exit stops, which are not real
signals at all.  It does affect the implicit SIGTRAP on exec when ptrace'd,
which is a normal signal.  All the events enabled by PTRACE_SETOPTIONS are
also not real signals.  This includes PTRACE_EVENT_EXEC (when requested by
PTRACE_O_TRACEEXEC), which replaces the implicit SIGTRAP on exec--so that
the problem goes away entirely.  

If strace were to use PTRACE_SINGLESTEP or inserts breakpoints, these also
interfere with a thread that blocks SIGTRAP.  In current kernels these
SIGTRAP's (unlike the exec one) are "forced" signals, which means that if
they are blocked or ignored, they will be both unblocked and reset to
SIG_DFL before queuing.  This means they will be seen by the ptracer
(strace), but also that the signal mask and sigaction will have been
changed out from under the program even if the ptracer swallowed this SIGTRAP.

I believe some past Linux kernels did not always do this "forced" behavior.
So there these SIGTRAPs (like the traditional exec one we still have) would
queue when blocked, and not be seen by the ptracer until the program
happened to unblock the signal.


Thanks,
Roland