Hi - On Mon, Jan 25, 2010 at 02:05:54PM -0700, Tom Tromey wrote: > [...] > Nevertheless, if the Linux kernel were to present a new user-space API, > and if it had an advantage over ptrace, then we would port GDB to use > it. There are other platforms where, IIRC, we now use some /proc thing > instead of ptrace. > > 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. > [...] Relatedly, don't mess with the inferior's parentage.
This is satisfied by the gdbstub prototype. > * Support "displaced stepping" in the kernel [...] I believe this is tantamount to hardware breakpoint support, which is already present (via optional uprobes). > * 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. This is in the todo list. And that "KILLER FEATURE" of running strace plus gdb on the same process? It *already works* with the gdbstub, and unmodified strace + gdb, thanks to utrace multiplexing process control. It is still artificially restricted in many ways, but this sort of thing is ready for testing: % process & [1] 9999 % strace -o FILE -p 9999 & % gdb process (gdb) target remote /proc/9999/gdb (gdb) backtrace (gdb) cont (gdb) ^D % [process continues] % cat FILE [...] % kill 9999 - FChE
