Re: linux-next: add utrace tree

Linus Torvalds
2010-01-26T18:47:13Z

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