From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6402 invoked by alias); 10 Feb 2011 20:00:21 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 6377 invoked by uid 22791); 10 Feb 2011 20:00:19 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Thu, 10 Feb 2011 20:00:00 -0000 From: Oleg Nesterov To: Roland McGrath Cc: Project Archer Subject: Re: ptrace improvement: PTRACE_O_INHERIT Message-ID: <20110210195212.GA3868@redhat.com> References: <20110203223905.D0C77180081@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110203223905.D0C77180081@magilla.sf.frob.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2011-q1/txt/msg00040.txt.bz2 On 02/03, Roland McGrath wrote: > > * PTRACE_O_INHERIT > > This is a new option bit for PTRACE_SETOPTIONS or the options argument of > PTRACE_ATTACH_NOSTOP. Its effect is that clones of the tracee inherit the > ptrace attachedness and option settings of their parent. Jan has already reminded about about debug registers. What else? Say, should TIF_SYSCALL_TRACE be copied? Suppose that we try adapt strace to this new option. > 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. > 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? 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). Not sure this makes any sense, but how "info treads" can work otherwise? > Because of this spontaneous report aspect, it could be difficult to figure > out what's going on with any new thread that is a fork/vfork, or other use > of clone (oddball applications, or old linuxthreads), rather than a > CLONE_THREAD case (NPTL pthread_create). In those cases, si_tgid and > si_pid are the same and neither matches any process you already know you > are tracing. In general, it can be impossible to figure out whose child > this is, because its parent could exit so its ppid (as seen in > /proc/pid/status et al) becomes 1. 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. 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? Nevermind, > 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. Oleg.