• LinuxKernelWishList

This is a wish list of features we'd like to see implemented in the Linux kernel. Scroll to the bottom for the list of kernel bugs we'd like fixed.

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.

• PR9425 - a way to handle SIGINT even when the inferior is stuck in sigwait.

• A way to set breakpoints using uprobes and have the kernel filter out uninteresting stops automatically.
• /proc/[pid]/map_files/ accessible even for non-root users.

  So that GDB can access the shared library files (w/ unmapped segments included) the program is actually running even if the files have been updated on disk since (e.g., through a distro update). But it has security implications (see the PR), it may never happen while GDB could use /proc/[pid]/mem as a good enough resource for unwinding. PR 16344

• A way for gdb to query the kernel to find the signal handlers installed for various signals. Then info signals could show the handlers. I'd also be useful for software single-step targets, to be able to step into signal handlers (gdb would need to place a single-step breakpoint in the handler).

• A way for gdb to request that it be attached to a process before it even starts. This would make it simpler to debug daemons and pipelines and the like. (The "global breakpoint" series dealt with this, so if it went in, that would be sufficient.)

• This thread has a few more ideas.

There are also a few ptrace/kernel bugs that affect GDB. Fixing these would be great.

• PR gdb/17511 Program received signal SIGTRAP, after step to signal handler -> step inside handler -> continue