From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32302 invoked by alias); 11 Feb 2011 19:24:34 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 32283 invoked by uid 22791); 11 Feb 2011 19:24:33 -0000 X-SWARE-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Oleg Nesterov X-Fcc: ~/Mail/utrace Cc: Project Archer Subject: Re: ptrace improvement: PTRACE_O_INHERIT In-Reply-To: Oleg Nesterov's message of Thursday, 10 February 2011 20:52:12 +0100 <20110210195212.GA3868@redhat.com> References: <20110203223905.D0C77180081@magilla.sf.frob.com> <20110210195212.GA3868@redhat.com> Message-Id: <20110211192423.78FFC1802A2@magilla.sf.frob.com> Date: Fri, 11 Feb 2011 19:24:00 -0000 X-SW-Source: 2011-q1/txt/msg00044.txt.bz2 > 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. Thanks, Roland