> In which specific cases SIGNR can get ignored? There are two fundamental kinds of ptrace stops: real signal stops, and "fake" (or "ptrace_notify()") stops. In the latter, you are not in the right place in the kernel for direct signal delivery, so it never works fully normally. All the optional event stops are in this latter category, i.e. everything not for a signal.
The syscall entry and exit stops have an explicit queuing behavior (i.e. it's about the same as if you'd just called tgkill before PTRACE_CONT--any PTRACE_SETSIGINFO you've done has no effect on this new signal, but you will see it in a real signal stop soon when it's dequeued). The others do not have any such kludge, so they just drop the signr argument on the floor. Note that the default exec stop really is a signal (a plain SIGTRAP sent as if by "raise(SIGTRAP);" right after exec), but PTRACE_EVENT_EXEC is not. Some of the PTRACE_SINGLESTEP cases on some architectures use fake stops. When stepping over an average user instruction, it's always a real SIGTRAP. But e.g., stepping the syscall insn on powerpc and some others (perhaps all but x86) is not. As Oleg mentioned, when PTRACE_SINGLESTEP,signr stops immediately after handler setup, that is also a fake stop. These cases are something that we probably can and should fix and arch-harmonize upstream so that PTRACE_SINGLESTEP consistently produces a real SIGTRAP signal stop after which the full range of I don't think the behavior for the special event stops will change. Thanks, Roland
