> 1. I assume that, on every arch, we alway check TIF_NOTIFY_RESUME > and TIF_SIGPENDING before TIF_SYSCALL_TRACE, right?
No, these are only checked when you would otherwise return to user mode. > IOW, can I assume that syscall_trace_leave() should not be called > before utrace_resume() or utrace_get_signal() ? No, if TIF_SYSCALL_TRACE is still set when sys_foo returns, then tracehook_report_syscall_exit will always be called first. Only after that do you get to "would otherwise return to user mode" state. > 2. We have to play tricks because there is no reporting loop > tracehook_report_vfork_done(). > > Why? I agree, UTRACE_EVENT(VFROKDONE) is meaningless because > we are going to return from syscall soon and the tracer can > see this event "for free". Right. It also seems more useful to me if the place you catch in the parent is at/after the syscall-exit tracing point, where the parent's return value register has the child's PID. > But perhaps there is another reason I missed? And, otoh, > why do we have PT_TRACE_VFORK_DONE ? If it is in fact useful, > then perhaps UTRACE_EVENT(VFROKDONE) is useful too? Personally I don't think PTRACE_O_TRACEVFORKDONE is particularly useful. That is, you could always just catch PTRACE_EVENT_VFORK in the parent and then use PTRACE_SYSCALL instead of PTRACE_CONT, and you'd know that what you catch next in the parent is the exit from the vfork/clone syscall. But it's part of the legacy ptrace ABI. I've thought that in the long run it might be nice to change the wait the vfork block works such that we could let a blocked vfork parent be considered "stopped enough" for tracing (and perhaps also so it could be SIGKILL'd without waiting for the child to die/exec). But that is its own whole can of worms. As well as the implementation, there is the whole hairy subject of what you want to be doing with the parent during the period of strange memory sharing. That's a thought for another day. Thanks, Roland
