This is the mail archive of the
mailing list for the Archer project.
Re: ptrace improvement: PTRACE_O_INHERIT
On 02/11, Roland McGrath wrote:
> > What else? Say, should TIF_SYSCALL_TRACE be copied?
> > Suppose that we try adapt strace to this new option.
> Let's talk about the userland interface features here,
Ah, I didn't mean implementation details, sorry.
> For strace as it is, I don't think there is really any benefit to using
> Another feature that has made obvious sense for a long time is to have
> PTRACE_O_TRACESYSCALL instead of just PTRACE_SYSCALL
Yes, and that is why I asked about TIF_SYSCALL_TRACE. Because to me
PTRACE_SYSCALL looks like a property/option regardless of implementation
But I agree, this was a bit off-topic.
> > Or. Suppose that clone() under PTRACE_O_INHERIT notifies the tracer
> > (sends SIGCHLD), and the new tracee gets the new PTRACE_O_INHERITed
> > mark. Then we can implement wait(W_WHO_WAS_CLONNED) which clears
> > PTRACE_O_INHERITed and reports the new tracee (just in case, this
> > doesn't need the stopped tracee).
> I don't really follow this idea at all, sorry.
I meant, we can intoduce the new W*** flag for do_wait(). If the new
tracee was PTRACE_O_INHERIT'ed, do_wait() returns its pid.
> > Not sure this makes any sense, but how "info treads" can work otherwise?
> It can always look as /proc/PID/task/ to enumerate threads.
Well yes, but /proc/PID/task/ is not convenient and reliable.
Especially if we do not trace all threads.
But, again, if this is fine to gdb - forget.
> > Not sure I really understand why this is the problem by itself. Yes, if
> > its ppid == 1, we know that the original parent was traced by us and then
> > it has gone.
> [... snip ...]
Hmm... Still can't understans right now, but this doesn't matter:
> > > So perhaps it would be better to have
> > > this be just PTRACE_O_THREAD_INHERIT, where it only applies to CLONE_THREAD
> > > clones.
> > Or we can have both.
> Indeed. But I want to add things that GDB is really going to use, not go
> hog-wild on speculative features
Yes, yes, agreed.
Damn. I was so unclear. I tried to say: yes, I think PTRACE_O_THREAD_INHERIT
makes more sense. If nothing else, the tracer doesn't necessarily wants to
follow forks, this can create the unneeded overhead if it only wants to ptrace
IOW, I think that we should have both, or PTRACE_O_THREAD_INHERIT only.
Or, this option should take "clone_flags" as an argument.