Subject: Re: linux-next: add utrace tree

From: Linus Torvalds <[email-masked]>
Date: Mon, 25 Jan 2010 13:41:57 -0800 (PST)

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