From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8693 invoked by alias); 16 Feb 2011 18:28:12 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 8683 invoked by uid 22791); 16 Feb 2011 18:28:11 -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 Wednesday, 16 February 2011 17:02:09 +0100 <20110216160209.GA19339@host1.dyn.jankratochvil.net> References: <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> <20110215214333.GA18086@host1.dyn.jankratochvil.net> <20110215220153.470031806E0@magilla.sf.frob.com> <20110216160209.GA19339@host1.dyn.jankratochvil.net> Message-Id: <20110216182807.CA9491806E0@magilla.sf.frob.com> Date: Wed, 16 Feb 2011 18:28:00 -0000 X-SW-Source: 2011-q1/txt/msg00060.txt.bz2 > That may be too asynchronous. After GDB/gcore/etc. finishes new PTRACE_ATTACH > must complete successfully. I never know if it is already guaranteed or not > but in practice it works now. Sorry if I was unclear, that is not the kind of asynchrony I was talking about. It is guaranteed now that when PTRACE_DETACH succeeds, the tracee is detached and can be attached anew. That would be true of what I suggested also. The asynchrony I mean is the good kind: that it doesn't have to be stopped for you to detach it. There is nothing special for a debugger to worry about with this asynchrony unless it uses multiple threads where one thread calls wait* while another thread calls ptrace. In that case, the debugger's wait* thread could see a stop result that appears to be after its other thread detached the same tracee. (That is already true now with PTRACE_DETACH.) If the debugger's own wait* call is strictly ordered after its detaching ptrace call, there can be no such confusion. > If there is no PTRACE_DETACH_ALL_TIDS(pid) and PTRACE_O_THREAD_INHERIT is in > use GDB probably has to repeatedly iterate /proc/PID/task/*/status till all > have TracerPid == 0. Indeed. That seems undesireable. > > the attach-group implementation will be sufficiently hairy that the kernel > > community would demand that we do some simpler incremental changes first > > before attempting it (such as what I proposed for ATTACH_NOSTOP, which > > eliminates the SIGSTOP and rolls in atomic option-setting). > > thread_db_find_new_threads_2 already does an ugly loop of repeated threads > finding. There are also some failures that can be probably fixed by changing > td_ta_thr_iter to readdir(/proc/PID/task) (RH#677654). There are some pending > bugs in GDB about it. I take that to mean that you do not see a strong demand for a group-attach feature, though having one would simplify things. (But since GDB will never get rid of its code to support older kernels, perhaps such simplification doesn't really help much in practice.) Thanks, Roland