This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ptrace improvement: PTRACE_O_INHERIT

On 02/14, Roland McGrath wrote:
> > I meant, I do not agree that it never makes sense to trace, say, a
> > single thread from the thread group. But since we are talking about
> > gdb my noncompliance is off-topic.
> We are also talking about what makes sense for a kernel interface, so it's
> certainly apropos to share our thoughts on the general subject.  Please
> elaborate on why you think this makes sense.  It's certainly true that it
> makes sense to have your tracing details different for one thread than for
> others (stopping on more events, etc.)

No, I didn't mean this (but I agree this is true).

> but that's quite a different thing
> from saying it really makes sense to have a debugging interface structured
> to consider tracing an individual thread as unrelated to tracing all the
> threads in the same process,

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.

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

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.

sure. IOW, the new thread doesn't exist (from gdb pov) until it reports
something interesting.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]