> Note that I don't really understand why I am worried ;) Nameless fears are the most effective ones!
> C recieves a signal, notices task_utrace_flags(), calls utrace_get_signal(), > dequeues the signal, calls E->ops->ptrace_report_signal() which returns > UTRACE_STOP. Ah, right. The important point is it returns UTRACE_SIGNAL_IGN|UTRACE_STOP. I overlooked this case, or perhaps I was wrongly thinking that it used UTRACE_SIGNAL_HOLD. (It doesn't and can't, because it needs to distinguish the signal it already reported from a new one, and also because an unrelated new one with a different (lower) signal number could be dequeued first on the second round.) An implicit detach (i.e. exit_ptrace) must act like a PTRACE_DETACH,signr for the last-reported signal. In old ptrace, that is implicit just in the ->exit_code value left behind and picked up on resume. Your implementation of this can probably just use the same method as for a real PTRACE_DETACH,signr. Just pick up last_siginfo->si_signo and use it. > In short. Perhaps I missed something, but I think it would be "safer" if > ptrace_attach() did utrace_set_events() after setting PT_PTRACED, but this > is not possible because attach sends SIGSTOP. [...] I don't really understand why the SIGSTOP is your concern. No matter what, you send that last, after ptrace is wired up to catch it. > Hmm. Strange, but I didn't think of another option... > > ptrace_attach_task() can check ->ptrace == 0 ! Something like Sorry, I've lost track of what this flag (that really shouldn't exist at all) means in your version that's distinct from whether you have the ptrace_utrace_ops engine attached. Thanks, Roland
