Re: ptrace improvement: PTRACE_O_INHERIT

[Roland McGrath <roland@redhat.com>]

> Yes, and I can't understand why this doesn't make sense.
> 
> I do not have any good example in mind. But if I want to know what this
> particular thread does, why should I trace the whole process? Not to
> mention, with the current ptrace interface it is never "free" to ptrace
> the threads you do not care about.

On this subject we are no longer talking about ptrace, since it is a
per-thread interface.  Quite simply, the notion of considering a thread in
isolation from its process just does not make any sense to me at all from
the perspective of a user or a debugger or anything in userland, or in the
abstract.  It only appears sensical at all because of the Linux kernel's
implementation details.

As I already mentioned, it is certainly sensical that any sane interface
would not require you to do anything that perturbs or slows all threads in
a process merely by the structure of the interface.  Naturally, just to be
"attached" to a process doesn't imply noticing any events that happen in it
except for the process going away entirely.

> If nothing else. I like the fact "strace -p" can trace the individual
> thread without disturbing the whole thread group.

If that's all you want to see, that's all you'd ask for.
I don't see what that has to do with structuring an interface
such that you pretend that a thread is an independent agent that
has no relationship with its containing process.

> And in fact I don't really understand why WCLONNED doesn't make sense
> in general. OK, probably gdb doesn't need it. As you said,
> 
> 	It supplies no new information, only mentions the tracee earlier.

(There would be only one N in that, btw.)  I don't think I said it didn't
make any sense at all.  I said it doesn't really address the problem of
tracking lineage.  That's the subject I was considering, since that's the
context in which you proposed it.

> OK, but I think PTRACE_O_INHERIT is useful in general, not only for gdb.
> And it looks a bit strange the tracer can't know what it traces. Especially
> because the current API is per-thread.
> 
> Suppose that debugger uses PTRACE_O_INHERIT and then it decides to detach
> gracefully. It should detach per-thread, but how? /proc is very unconvenient.
> Even if we traced all threads, we do not trace them all after we detach
> the first thread, and that thread can clone the new threads after detach.

That is a good point, and relevant to GDB's use.  If this were the
interface, then certainly it would need a way to know what to detach.
This highlights how it's all a highly unnatural interface for what a
debugger really wants to do.  But in considering small incremental
improvements to ptrace, we need to contemplate such issues.

This is an example of how the clean, new, non-ptrace, high-level interface
that I always imagined would be far more natural.  In that notion, the
debugger would define a "tracing group" (always needed a better term for
that) that is its handle on referring to what it's doing in the interface.
Things like automatic attaching of new threads or children would be in the
context of a particular tracing group, and graceful detach could also
operate on the basis of releasing an entire tracing group.  But, all that
gets us away into the land of "good ideas" rather than "ptrace improvement".


Thanks,
Roland