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

> > > 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.
> To simplify the explanation, suppose we add task_struct->unknown_tracee
> boolean.
> if tracehook_finish_clone()->ptrace_init_task() does __ptrace_link()
> because of PTRACE_O_INHERIT, it also sets child->unknown_tracee and
> notifies the tracee via do_notify_parent_cldstop().

So the suggestion is to have the tracer see a wait report that simply says
"here is a new implicit tracee".  I don't see how that is useful at all.
It supplies no new information, only mentions the tracee earlier.  That
makes it a short race window in which it's possible for a tracer to have no
possible means of identifying the lineage of an implicit tracee.  But it
does not solve the problem in the general case.

> > 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.
> Off-topic note: I disagree very much, but this doesn't matter. I agree
> that ptrace nterface should not be per-thread, and gdb always traces all
> threads.

Then I don't understand at all what you are disagreeing with.
You think the interface should not be per-thread, but you don't agree
that a per-thread interface is not something debuggers really want?


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