This is a wish list of features we'd like to see implemented in the Linux kernel.
In no particular order:
* A PTRACE_GET_SIGINFO variant that returns the siginfo_t object in the architecture of the inferior, rather than the architecture of the kernel.
- When debugging a 32-bit program on a 64-bit system, GDB currently needs to try to do the same siginfo_t layout conversion (to/from compat layout) the kernel knows best how to do. This is mainly used for "p $_siginfo".
* TRAP_BRKPT on x86 (better, on all archs that need to unwind the PC on breakpoints. Better yet, on all archs).
It would be useful for the kernel to tell us whether a SIGTRAP corresponds to a breakpoint hit or a finished single-step (or something else), without having to resort to heuristics. Checking for the existence of an int3 in memory at PC-1 is not a complete solution, as the breakpoint might be gone already. This is actually useful both for ptracers and in-process self debuggers.
Some archs started encoding trap discrimination on SIGTRAPs si_code. E.g., on PPC boxes one can see:
/* `si_code' values for SIGTRAP signal. */
enum
{
TRAP_BRKPT = 1, /* Process breakpoint. */
# define TRAP_BRKPT TRAP_BRKPT
TRAP_TRACE /* Process trace trap. */
# define TRAP_TRACE TRAP_TRACE
};But unfortunately, x86 doesn't implement this.
* A PTRACE_O_SYSCALL(_ENTER|_EXIT) ptrace option, along with PTRACE_EVENT_SYSCALL(_ENTER|_EXIT).
- PTRACE_SYSCALL/sysgood doesn't leave any way to trace syscalls when single-stepping. Separate syscall enter and exit events would just be nice, to avoid having to keep track of enter/exit - the kernel knows, might as well give us the info. (While at it, a way to filter which syscalls trigger events would be nice to avoid unnecessary slowing down the inferior until it calls the syscall the user is interested in (you can catch specific syscalls with "catch syscall foosyscall"; gdb currently filters after the fact), though that's obviously a bit more work.)
* A way to filter which signals the tracer is interested in.
- IOW, let the tracer tell the kernel it is not interested in a set of signals. With "handle SIGFOO pass nostop noprint", the only thing GDB does when ptrace reports the child stopped with SIGFOO, is resume the child process immediately. With such a mechanism, the stop (that slows down inferior execution) would be completely avoided.
* A way to use ptrace without signals or wait.
- The current approach clashes with many common GUI toolkits, that arrange to handle SIGCHLD themselves, sometimes in ways that interfere with debugger operation. One way to make this work nicely would be a PTRACE_FD request, which would return a file descriptor; the kernel could write the wait-style status directly to the fd.
* This thread has a few more ideas.