From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30979 invoked by alias); 16 Feb 2011 20:00: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 30963 invoked by uid 22791); 16 Feb 2011 20:00:26 -0000 X-SWARE-Spam-Status: No, hits=-6.4 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: Wed, 16 Feb 2011 20:00:00 -0000 From: Oleg Nesterov To: Roland McGrath Cc: Jan Kratochvil , Project Archer Subject: Re: ptrace improvement: PTRACE_O_INHERIT Message-ID: <20110216195213.GD15576@redhat.com> References: <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> <20110216182807.CA9491806E0@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110216182807.CA9491806E0@magilla.sf.frob.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2011-q1/txt/msg00067.txt.bz2 On 02/16, Roland McGrath wrote: > > > 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 Yes, but I can' understand the next part: > 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. Could you spell please? Just curious. Oleg.