From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20426 invoked by alias); 15 Feb 2011 13:16:19 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 20416 invoked by uid 22791); 15 Feb 2011 13:16:17 -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: Tue, 15 Feb 2011 13:16:00 -0000 From: Oleg Nesterov To: Roland McGrath Cc: Project Archer Subject: Re: ptrace improvement: PTRACE_O_INHERIT Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110215003551.BC1EA1802A2@magilla.sf.frob.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2011-q1/txt/msg00053.txt.bz2 On 02/14, Roland McGrath wrote: > > > I meant, I do not agree that it never makes sense to trace, say, a > > single thread from the thread group. But since we are talking about > > gdb my noncompliance is off-topic. > > We are also talking about what makes sense for a kernel interface, so it's > certainly apropos to share our thoughts on the general subject. Please > elaborate on why you think this makes sense. It's certainly true that it > makes sense to have your tracing details different for one thread than for > others (stopping on more events, etc.) No, I didn't mean this (but I agree this is true). > but that's quite a different thing > from saying it really makes sense to have a debugging interface structured > to consider tracing an individual thread as unrelated to tracing all the > threads in the same process, 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. If nothing else. I like the fact "strace -p" can trace the individual thread without disturbing the whole thread group. 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. sure. IOW, the new thread doesn't exist (from gdb pov) until it reports something interesting. 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. Oleg.