From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13890 invoked by alias); 4 Feb 2011 18:56:30 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 13881 invoked by uid 22791); 4 Feb 2011 18:56:29 -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: Fri, 04 Feb 2011 18:56:00 -0000 From: Oleg Nesterov To: Roland McGrath Cc: Project Archer Subject: Re: ptrace improvement ideas Message-ID: <20110204184832.GA20887@redhat.com> References: <20110203223905.D0C77180081@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110203223905.D0C77180081@magilla.sf.frob.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2011-q1/txt/msg00027.txt.bz2 On 02/03, Roland McGrath wrote: > > I don't want to propose any specific changes to the kernel community > off the cuff. We need to work out details with GDB hackers so that we > have things that really improve life in GDB, and that GDB hackers will > really make use of quite soon. It's worse than nothing to add or > change things in the kernel interfaces before GDB folks are ready to > really work on using them, so that we can be quite sure that the > details and corner cases are thoroughly-specified and done so in ways > that really work well for GDB in practice. Yes. Right now I have nothing to add ;) I'll try to think more, but every proposal looks as "obviously makes sense" to me. However, I do not know what is useful for GDB. Only one note, > * PTRACE_ATTACH_NOSTOP How about PTRACE_DETACH_NOSTOP? Like PTRACE_DETACH, but doesn't require the stopped tracee. I was really amazed when I looked into strace sources. The code which handles detach is soooooo complicated (and I do not blame strace). But, again, I do not know if this makes sense for GDB. Oleg.