From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Frank Ch. Eigler" Subject: Re: linux-next: add utrace tree Date: Sat, 23 Jan 2010 06:51:49 -0500 Message-ID: <20100123115149.GB7828@redhat.com> References: <20100121170541.7425ff10.akpm@linux-foundation.org> <20100122182827.GA13185@redhat.com> <20100122200129.GG22003@redhat.com> <20100122221348.GA4263@redhat.com> <20100123110121.1ce89bb9@lxorguk.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20100123110121.1ce89bb9@lxorguk.ukuu.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: utrace-devel-bounces@redhat.com Errors-To: utrace-devel-bounces@redhat.com To: Alan Cox Cc: Stephen Rothwell , Kyle Moffett , Peter Zijlstra , Peter Zijlstra , Fr??d??ric Weisbecker , Oleg Nesterov , Steven Rostedt , LKML , Arnaldo Carvalho de Melo , linux-next@vger.kernel.org, "H. Peter Anvin" , utrace-devel@redhat.com, Linus Torvalds , Thomas Gleixner List-Id: linux-next.vger.kernel.org Hi - On Sat, Jan 23, 2010 at 11:01:21AM +0000, Alan Cox wrote: > [...] > What I don't understand is why [libgdb?] doesn't solve 99% of your problem. > ptrace is not perfect but most of the real ptrace limitations actually > come about because either the CPU can't do something or because the > supporting logic would be too expensive - things like having extra > private debugger pages. At least one reason is that ptrace is single-usage-only, so for example you cannot concurrently debug & strace the same program. OTOH, utrace is designed to permit clean nesting/sharing semantics for concurrent debugger-type tools operating on the same processes. - FChE