Re: linux-next: add utrace tree

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 26 Jan 2010, Andi Kleen wrote:

> Tom Tromey <tromey@redhat.com> writes:
> 
> > * 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.
> 
> How would having a kernel based solution be better over your
> user space simulation?

Oh, the reason we should do something in the kernel is that you really 
can't do certain things with the ptrace() interface. 

For example, think about how Wine and UML use ptrace - and then realize 
that that makes it impossible to attach a debugger from the outside. 
That's a real deficiency in ptrace - much more so than the fact that there 
are some odd details (ie the whole "read/write a word at a time" is just a 
quirky detail in comparison - not a fundamental problem).

> BTW there's the new signalfd() system call that might do it
> (haven't checked if it works for SIGCHLD)

No, you miss the point.

The problem isn't that you want to turn signals into a file descriptor 
just because you like file descriptors.

The problem is that anything that is based on reparenting and signals is 
fundamentally a "one parent only" kind of interface. See?

So the reason I think using an fd is a good idea is _not_ because gdb 
already uses an fd internally, but because it gives you a "connection" 
between the debugger and debuggee that is not fundamentally limited to a 
single controller.

(It doesn't have to be a file descriptor, of course, but could be any kind 
of other model that allows multiple connections. It's just that in unix 
terms, using a file descriptor as the "cookie" for the connection is a 
very natural model. So the important part isn't the file descriptor 
itself, it's the model you could build).

			Linus