On Tue, 26 Jan 2010, Andi Kleen wrote: > Tom Tromey <tromey@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
