This is the mail archive of the archer@sourceware.org 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 Tue, 15 Feb 2011 14:08:05 +0100, Oleg Nesterov wrote:
> And it looks a bit strange the tracer can't know what it traces.

With PTRACE_O_INHERIT GDB can no longer know as any thread can disappear any
time.  But even GDB does not care much, it has the list stale and updates it
by update_thread_list() during `info threads' and similar commands.
GDB also never trusts the found threads list, it does tkill (TID, 0) to verify
if any TID is still alive.


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

Maybe it is obvious but it has not been heard yet.
With PTRACE_O_THREAD_INHERIT the debugger no longer has to enumerate threads
for ptrace operations - except for attach+detach.

Could PTRACE_ATTACH_NOSTOP+PTRACE_DETACH_NOSTOP? act on the whole PID at once
if PTRACE_O_THREAD_INHERIT is applied - already during PTRACE_ATTACH_NOSTOP?
It is a bit overloading the *_NOSTOP meaning but it is a new PTRACE_* op.


Thanks,
Jan


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