Re: ptrace improvement: PTRACE_O_INHERIT

[Roland McGrath <roland at redhat dot com>]

> Yes, and that is why I asked about TIF_SYSCALL_TRACE. Because to me
> PTRACE_SYSCALL looks like a property/option regardless of implementation
> details.

But it's only if you're looking at implementation details rather than the
userland interface that you'd think any such thing.

> > > 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.

I still don't understand the proposal.

> Well yes, but /proc/PID/task/ is not convenient and reliable.
> Especially if we do not trace all threads.

Tracing some threads but not all is really an artifact of the ptrace
interface and not something that any real userland debugger-like thing
ever wants to do.

> 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
> the sub-threads.
> 
> IOW, I think that we should have both, or PTRACE_O_THREAD_INHERIT only.

That sounds reasonable (which is why I suggested it in the first place ;-).
But, again, we want to see what GDB really wants to use and only add that.

> Or, this option should take "clone_flags" as an argument.

That is far less straightforward to implement in the vanilla kernel as it
stands today, and so really doesn't fall under the "low hanging fruit" rubric.


Thanks,
Roland