> 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 ------------------------------------------------------------------------------ _______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
