Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753925Ab0AYVmp (ORCPT ); Mon, 25 Jan 2010 16:42:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753869Ab0AYVml (ORCPT ); Mon, 25 Jan 2010 16:42:41 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:59667 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595Ab0AYVmj (ORCPT ); Mon, 25 Jan 2010 16:42:39 -0500 Date: Mon, 25 Jan 2010 13:41:57 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Tom Tromey cc: Kyle Moffett , "Frank Ch. Eigler" , Oleg Nesterov , Andrew Morton , Stephen Rothwell , Peter Zijlstra , Peter Zijlstra , Fr??d??ric Weisbecker , LKML , Steven Rostedt , Arnaldo Carvalho de Melo , linux-next@vger.kernel.org, "H. Peter Anvin" , utrace-devel@redhat.com, Thomas Gleixner Subject: Re: linux-next: add utrace tree In-Reply-To: Message-ID: References: <20100121013822.28781960.sfr@canb.auug.org.au> <20100122005147.GD22003@redhat.com> <20100121170541.7425ff10.akpm@linux-foundation.org> <20100122182827.GA13185@redhat.com> <20100122200129.GG22003@redhat.com> <20100122221348.GA4263@redhat.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2259 Lines: 50 On Mon, 25 Jan 2010, Tom Tromey wrote: > > There are definitely things we would like from such an API. Here's a > few I can think of immediately, there are probably others. > > * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb. > Internally we're already using a self-pipe to integrate this into > gdb's main loop. Relatedly, don't mess with the inferior's parentage. As I kind of alluded to elsewhere, I heartily agree with this. The really major design mistake of ptrace (as opposed to just various ugly corners) is how it has no connection information, and that ends up being one of the main reasons why you can't have two ptracers working on the same thing. (There are other things that complicate that too, of course, like simply just trying to manage various per-thread state like debug registers etc, but that's a separate class of complications). > * Support "displaced stepping" in the kernel; I think this would improve > performance when debugging in non-stop mode. Don't we already do that at least on x86? Just doing a single-step should work on an instruction even if it has a breakpoint on it, because we set the TF bit. Or maybe I'm not understanding what displaced stepping means to you. > * Support some kind of breakpoint expression in the kernel; this would > improve performance of conditional breakpoints. Perhaps the existing > gdb agent expressions could be used. I suspect it might be reasonable to do simple expressions on breakpoints, but not the kind of things gdb exports to users. IOW, maybe you could have a single conditional on a single value (register or memory) associated with an expression. Regardless, internally to the kernel your two later issues are "details". The "how to connect to the debuggee" is a much more fundamental issue, and has the biggest design/interface impact. The other would likely just be new ptrace command extensions that somebody would have to just implement the grotty details on. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/