From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2074 invoked by alias); 12 Feb 2011 00:59:10 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 2063 invoked by uid 22791); 12 Feb 2011 00:59:10 -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 Friday, 11 February 2011 21:37:55 +0100 <20110211203755.GA5367@redhat.com> References: <20110203223905.D0C77180081@magilla.sf.frob.com> <20110210195212.GA3868@redhat.com> <20110211192423.78FFC1802A2@magilla.sf.frob.com> <20110211203755.GA5367@redhat.com> Message-Id: <20110212005855.E764C1814A4@magilla.sf.frob.com> Date: Sat, 12 Feb 2011 00:59:00 -0000 X-SW-Source: 2011-q1/txt/msg00048.txt.bz2 > Yes, and that is why I asked about TIF_SYSCALL_TRACE. Because to me > PTRACE_SYSCALL looks like a property/option regardless of implementation > details. But it's only if you're looking at implementation details rather than the userland interface that you'd think any such thing. > > > 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. > > 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. > Well yes, but /proc/PID/task/ is not convenient and reliable. > Especially if we do not trace all threads. 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. > Damn. I was so unclear. I tried to say: yes, I think PTRACE_O_THREAD_INHERIT > makes more sense. If nothing else, the tracer doesn't necessarily wants to > follow forks, this can create the unneeded overhead if it only wants to ptrace > the sub-threads. > > IOW, I think that we should have both, or PTRACE_O_THREAD_INHERIT only. That sounds reasonable (which is why I suggested it in the first place ;-). But, again, we want to see what GDB really wants to use and only add that. > Or, this option should take "clone_flags" as an argument. That is far less straightforward to implement in the vanilla kernel as it stands today, and so really doesn't fall under the "low hanging fruit" rubric. Thanks, Roland