From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4907 invoked by alias); 15 Feb 2011 22:17: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 4897 invoked by uid 22791); 15 Feb 2011 22:17:34 -0000 X-SWARE-Spam-Status: No, hits=-4.8 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 Tuesday, 15 February 2011 14:08:05 +0100 <20110215130805.GA30742@redhat.com> References: <20110203223905.D0C77180081@magilla.sf.frob.com> <20110210195212.GA3868@redhat.com> <20110211192423.78FFC1802A2@magilla.sf.frob.com> <20110211203755.GA5367@redhat.com> <20110212005855.E764C1814A4@magilla.sf.frob.com> <20110212190253.GA31866@redhat.com> <20110214193052.3EC8D1814BA@magilla.sf.frob.com> <20110214193812.GA20765@redhat.com> <20110215003551.BC1EA1802A2@magilla.sf.frob.com> <20110215130805.GA30742@redhat.com> Message-Id: <20110215221723.9597E1806E0@magilla.sf.frob.com> Date: Tue, 15 Feb 2011 22:17:00 -0000 X-SW-Source: 2011-q1/txt/msg00057.txt.bz2 > Yes, and I can't understand why this doesn't make sense. > > I do not have any good example in mind. But if I want to know what this > particular thread does, why should I trace the whole process? Not to > mention, with the current ptrace interface it is never "free" to ptrace > the threads you do not care about. On this subject we are no longer talking about ptrace, since it is a per-thread interface. Quite simply, the notion of considering a thread in isolation from its process just does not make any sense to me at all from the perspective of a user or a debugger or anything in userland, or in the abstract. It only appears sensical at all because of the Linux kernel's implementation details. As I already mentioned, it is certainly sensical that any sane interface would not require you to do anything that perturbs or slows all threads in a process merely by the structure of the interface. Naturally, just to be "attached" to a process doesn't imply noticing any events that happen in it except for the process going away entirely. > If nothing else. I like the fact "strace -p" can trace the individual > thread without disturbing the whole thread group. If that's all you want to see, that's all you'd ask for. I don't see what that has to do with structuring an interface such that you pretend that a thread is an independent agent that has no relationship with its containing process. > And in fact I don't really understand why WCLONNED doesn't make sense > in general. OK, probably gdb doesn't need it. As you said, > > It supplies no new information, only mentions the tracee earlier. (There would be only one N in that, btw.) I don't think I said it didn't make any sense at all. I said it doesn't really address the problem of tracking lineage. That's the subject I was considering, since that's the context in which you proposed it. > OK, but I think PTRACE_O_INHERIT is useful in general, not only for gdb. > And it looks a bit strange the tracer can't know what it traces. Especially > because the current API is per-thread. > > Suppose that debugger uses PTRACE_O_INHERIT and then it decides to detach > gracefully. It should detach per-thread, but how? /proc is very unconvenient. > Even if we traced all threads, we do not trace them all after we detach > the first thread, and that thread can clone the new threads after detach. That is a good point, and relevant to GDB's use. If this were the interface, then certainly it would need a way to know what to detach. This highlights how it's all a highly unnatural interface for what a debugger really wants to do. But in considering small incremental improvements to ptrace, we need to contemplate such issues. This is an example of how the clean, new, non-ptrace, high-level interface that I always imagined would be far more natural. In that notion, the debugger would define a "tracing group" (always needed a better term for that) that is its handle on referring to what it's doing in the interface. Things like automatic attaching of new threads or children would be in the context of a particular tracing group, and graceful detach could also operate on the basis of releasing an entire tracing group. But, all that gets us away into the land of "good ideas" rather than "ptrace improvement". Thanks, Roland