From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23566 invoked by alias); 9 Feb 2011 02:48:27 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 23557 invoked by uid 22791); 9 Feb 2011 02:48:26 -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: Jan Kratochvil X-Fcc: ~/Mail/utrace Cc: Project Archer , Oleg Nesterov Subject: Re: ptrace improvement ideas In-Reply-To: Jan Kratochvil's message of Tuesday, 8 February 2011 21:40:50 +0100 <20110208204050.GA15482@host1.dyn.jankratochvil.net> References: <20110203223905.D0C77180081@magilla.sf.frob.com> <20110207211129.GA23277@host1.dyn.jankratochvil.net> <20110208015844.B994A1814A4@magilla.sf.frob.com> <20110208204050.GA15482@host1.dyn.jankratochvil.net> Message-Id: <20110209024815.C02311814AA@magilla.sf.frob.com> Date: Wed, 09 Feb 2011 02:48:00 -0000 X-SW-Source: 2011-q1/txt/msg00039.txt.bz2 > -> linux_nat_has_pending_sigint -> maybe_clear_ignore_sigint > > http://sourceware.org/ml/gdb-patches/2005-04/msg00041.html > > without it single CTRL-C gets reported for each process in a process group: That is a correct and true report of what actually happens. When you hit C-c, each process in the process group does get a SIGINT and can handle it independently. I can't see wanting anything different for the test case you show (except perhaps more sophisticated 'handle' commands to say I wanted something more automagic). The old mailing list thread you cited talks about the LinuxThreads case. That's a case where the user perception of the program is that it's one process with multiple threads, but the implementation has the kernel semantics of many processes that just share the memory address space and not much else. That is quite a different situation than several normal processes in a process group, as we encounter today (where the only kind of multithreadedness is NPTL). > > The point of using waitid is that you can see the new si_tgid field, and > > hence receive both the thread-specific ID and the process-wide TGID for a > > tracee that you haven't seen before. > > GDB has linux_proc_get_tgid :-) but only to workaround nptl/5983 fixed by you, > again reading "/proc/%d/status", for "Tgid". Sure, there is old stuff. The point of the si_tgid/waitid hack is to relieve GDB of the need to do that ungainly open+read+parse work when just dealing with the "new normal" of low-overhead multithread tracing. What you need to tell us is whether it is worthwhile to GDB that we add such features or not. If it's not a problem for GDB to use the crufty old /proc mechanism when faced with the wait result of an unknown ID, then we won't bother with the si_tgid changes in the kernel. I had been thinking it would be another scaling constraint and/or unpleasant corner case to have to deal with that. Perhaps it's really not a problem, since you only have to do that work when a thread actually stops and thus everything is slowing down anyway. You tell us. > PTRACE_O_INHERIT cannot be used for fork/vfork with `set detach-on-fork on' > (the default mode, so that it is not multi-inferior) as GDB needs to remove > software breakpoints. But the goal is multi-inferior `set detach-on-fork off' > anyway so in that mode PTRACE_O_INHERIT could apply even for fork/vfork. Ok. So that sounds like PTRACE_O_INHERIT as I described (applying to all kinds of clones) is indeed the useful way to define the feature. > `stopped_pids' tracks tasks which got reported as stopped before the parent's > PTRACE_EVENT_{CLONE,FORK,VFORK} has been seen. > > With multi-inferior `set detach-on-fork off', with no > PTRACE_O_TRACE{CLONE,FORK,VFORK} and using PTRACE_O_INHERIT it could apply for > both clones and forks/vforks, couldn't it? There is no longer any need to > track `stopped_pids'. This seems to be a question about gdb internals and I can't answer it for you. In the status quo, the only case where you can see an unexpected tracee is the race between parent and new child reporting, when the child reports first. There you can immediately do another blocking wait and be sure that you will see the parent report soon and can make the correlation. With the proposed new situation, you could see an unexpected new tracee that is a fork/vfork (or any non-CLONE_THREAD clone) and have no reliable way whatsoever to know where that new child came from. You can attempt to look up its ppid in /proc/pid/status and correlate that with some other tracee, but it's possible that its ppid is already 1 when the parent has died, so you won't know. (It's also possible that its ppid is another tracee you don't yet know about, so you'd have to iterate on the /proc lookup to follow the lineage back to one you know.) The question is, do you care? I am guessing that you have to care, because you need to know what known tracee was the proximate ancestor to know what breakpoints are already inserted in the new child. But it's for you to tell us. > PTRACE_O_TRACEEXEC still needs to stop the inferior as GDB needs to reinsert > all the software breakpoints to their newly computed addresses. Indeed. The PTRACE_O_INHERIT idea only attempts to relieve the need to use PTRACE_O_TRACE{CLONE,FORK,VFORK} when you don't want those events to be reported with stops. It has no bearing on other kinds of event stops you do want. Thanks, Roland