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

> What else? Say, should TIF_SYSCALL_TRACE be copied?
> Suppose that we try adapt strace to this new option.

Let's talk about the userland interface features here, rather than
implementation details.  The only interface today is PTRACE_SYSCALL, which
is not an ongoing state but only a one-shot action.  I don't think it makes
sense to talk about "inheriting" the fact that PTRACE_SYSCALL is in flight.

For strace as it is, I don't think there is really any benefit to using
PTRACE_O_INHERIT.  An strace tracee is going to stop for every syscall
anyway, so the addition child-startup stop and clone stops are not really a
significantly greater overhead than what it's already always going to have.

Another feature that has made obvious sense for a long time is to have
PTRACE_O_TRACESYSCALL instead of just PTRACE_SYSCALL (or perhaps separate
PTRACE_O_TRACE_SYSCALL_{ENTRY,EXIT} flags).  That would be a permanent
state flag like the other PTRACE_O_TRACE* flags, meaning that syscall
entry/exit events would cause event stops regardless of which flavor of
PTRACE_CONT/SINGLESTEP/etc was last used to resume the thread.  (For any
such new feature it would also make sense to have those use a clean
PTRACE_EVENT_SYSCALL_{ENTRY,EXIT} stop code instead of the silly
TRACESYSGOOD magic format.)  

If we had that, then it would follow naturally that these option flags
would be inherited like all the others.  But AFAIK there has not really
been any practical demand for this cleanup from ptrace users.  It is
straightforward enough to add, and a nice cleanup IMHO.  So perhaps we
should consider doing this anyway.  I can imagine that gdb might like to
use it, anyway.

> > This has no other effects, meaning it does not cause
> > either the parent or the child to stop for any event.
> Somehow I am starting to feel uncomfortable. The debugger traces the
> thread and doesn't even know about this fact. And can't know until the
> first report. But once again, if this is fine for gdb - please ignore.

That's why I'm asking Jan et al to direct us more about these details.

> > The point of PTRACE_O_INHERIT would be to attach newly-created threads and
> > children without causing an event stop and the attendant overhead.
> OK, PTRACE_EVENT_FORK stops both, parent and child. But we can implement
> PTRACE_O_INHERIT so that only the new child/thread stops. Or this doesn't
> help enough?

My impression of what Jan asked for was "no slowdown" on thread creations
without other interesting events.  For normal debugging scenarios at the
macro level, it's really not an interesting event that a new thread was
created, only when a breakpoint/crash/etc happens.

> Or. Suppose that clone() under PTRACE_O_INHERIT notifies the tracer
> (sends SIGCHLD), and the new tracee gets the new PTRACE_O_INHERITed
> mark. Then we can implement wait(W_WHO_WAS_CLONNED) which clears
> PTRACE_O_INHERITed and reports the new tracee (just in case, this
> doesn't need the stopped tracee).

I don't really follow this idea at all, sorry.

> Not sure this makes any sense, but how "info treads" can work otherwise?

It can always look as /proc/PID/task/ to enumerate threads.  (And there are
also the libthread_db means, though AIUI those are now deprecated.)

> Not sure I really understand why this is the problem by itself. Yes, if
> its ppid == 1, we know that the original parent was traced by us and then
> it has gone.

GDB needs to know which of its tracees was the parent (or grandparent or
great-grandparent, etc.) to know what set of text-insertion breakpoints it
has in its memory, inherited watchpoints its threads have, etc.  Otherwise
at a SIGTRAP on an unrecognized new task it has no way to line up what it's
talking about at all.

> Suppose that we (to simplify the discussion) introduce task->original_ppid,
> then we can "solve" the problem and report this pid to gdb. But given that
> it has already died, how this can help?

If it has already died but GDB knows exactly what process that was from the
PPID, then it knows what tracing state, breakpoints, etc. were inherited.

But you may need the full ancestry, not just the immediate parent.  If it's
already dead and GDB had never known about it, then GDB still doesn't know
anything.  However, if GDB is still getting all death reports, possibly
that could be enough for the ancestry to add up, though there are races and
corners there I think.

> > So perhaps it would be better to have
> > this be just PTRACE_O_THREAD_INHERIT, where it only applies to CLONE_THREAD
> > clones.
> Or we can have both.

Indeed.  But I want to add things that GDB is really going to use, not go
hog-wild on speculative features that might never be used or might wind up
having subtly different semantics than what is really worthwhile for GDB.


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