Speaker
Description
While is GDB is primarily a user space tool, drgn is a kernel space one. Using them together may improve user experience as drgn can help GDB to get access to various kernel structures. Right now, GDB can show what a thread is doing in user space, drgn can show what it is doing in the kernel — but the two tools do not talk to each other. I would like to discuss what it would mean to cross that border.
The crossing is technically straightforward: drgn is a Python library, and GDB already has a Python API, making it natural to call drgn from GDB scripts. As a concrete demonstration, I wrote a small GDB Python command, drgn_why_sleeping, which retrieves the kernel stack of a sleeping thread via drgn and displays it alongside GDB's user-space backtrace — showing the full kernel path where bt alone shows only a generic syscall frame.
This raises further questions: could drgn's per-frame register and local variable access allow GDB users to inspect kernel frames interactively? Is a remote variant worth pursuing for kgdb setups? Could drgn help trace where in the kernel an error originates when stepping over a failing syscall? Valgrind could also benefit — since drgn does not use ptrace, it could attach to a Valgrind-instrumented process simultaneously and resolve invalid memory addresses to named kernel structures. And in the other direction: could user-space tools like GDB or Valgrind offer anything useful back to drgn?