> > In short, PTRACE_EVENT_SIGTRAP provides bug compatibility for > > PTRACE_SINGLESTEP,signr silently acting like PTRACE_SINGLESTEP,0 when > > (s/PTRACE_SINGLESTEP/PTRACE_ANY/)
Right. > > Does that all sound right to you, or did I miss something? > > Don't ask me, I never know what can be changed ;) :-) I only meant to ask that you verify all my factual statements. You are on the hook for being sure about what exactly what the behaviors are now and would be if changed how. I can represent whether given exact changes are good fixes or bad incompatibilities. > But yes, I agree. The current behaviour looks strange (if not wrong). > With this change ptrace(PTRACE_WHATEVER, signr) after PTRACE_SINGLESTEP > never ignores signr. Even if perhaps this is not really useful, this is > consistent. Afaics, this case was a single exception when ptrace(signr) > or PTRACE_SETSIGINFO) was ignored after PTRACE_SINGLESTEP. Aside from any resumption after a PTRACE_O_TRACE* stop, yes, I think it is. > The only problem with this change (if we do it now), it is always nice > to have a separate changelog to document the behaviour change. But > hopefully nobody cares, I mean, nobody will notice the difference. This seems like something we could change upstream first, to clarify and separate the behavior change. If the arch bits about choosing si_code et al are resolved, then it is simple to make the old kernel's tracehook calls post a signal instead of using ptrace_notify. Thanks, Roland
