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

OK, lets forget then.

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

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.


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