From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15626 invoked by alias); 21 Feb 2011 19:44:56 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 15614 invoked by uid 22791); 21 Feb 2011 19:44:56 -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: Jan Kratochvil X-Fcc: ~/Mail/utrace Cc: Oleg Nesterov , Project Archer Subject: Re: ptrace improvement: PTRACE_O_INHERIT In-Reply-To: Jan Kratochvil's message of Saturday, 19 February 2011 20:47:58 +0100 <20110219194758.GA8994@host1.dyn.jankratochvil.net> References: <20110212190253.GA31866@redhat.com> <20110214193052.3EC8D1814BA@magilla.sf.frob.com> <20110214193812.GA20765@redhat.com> <20110215003551.BC1EA1802A2@magilla.sf.frob.com> <20110215130805.GA30742@redhat.com> <20110215214333.GA18086@host1.dyn.jankratochvil.net> <20110215215634.2665A1806E0@magilla.sf.frob.com> <20110216193356.GB15576@redhat.com> <20110216194534.2D39018020E@magilla.sf.frob.com> <20110216200110.GA17601@redhat.com> <20110219194758.GA8994@host1.dyn.jankratochvil.net> Message-Id: <20110221194447.47ABE1814AE@magilla.sf.frob.com> Date: Mon, 21 Feb 2011 19:44:00 -0000 X-SW-Source: 2011-q1/txt/msg00088.txt.bz2 > (a) GDB tracks separately threads (libpthread-managed) and LWPs (TIDs). > (So the libthread_db TD_DEATH notification is offtopic for this mail.) Then the scalability issues with thread creation and death will not be algorithmically improved (only halved at best) by making the automatic kernel notifications less eager. GDB will have to stop enabling the libthread_db event breakpoints for thread creation and death before the stuff we are discussing really matters. > (b) For LWPs it does not use PTRACE_O_TRACEEXIT. > /* Do not enable PTRACE_O_TRACEEXIT until GDB is more prepared to support > read-only process state. */ > (I do not know more regarding this comment.) I don't know from the GDB side what the details are, but I might be able to offer a little insight here. At the PTRACE_EVENT_EXIT stop, you have what looks like any other ptrace stop, where you can fetch and set the registers and so forth. But the tracee thread has already started exiting and it will never return to user mode, no matter what you do. So it's impossible to do "jump", an inferior function call, etc.--for changing registers to have any kind of effect (except on the contents of a core dump initiated by another thread). Thanks, Roland