Linux kernel debugging and other features

[Thomas Caputi <tcaputi at datto dot com>]

Hello gdb,

My name is Tom Caputi and I am a developer for ZFS on Linux. Recently,
I had the opportunity to work with some members of Delphix (another
major ZFS on Linux contributor) to build some debugging tools.

When we started working on this project we were surprised to see how
close gdb was to supporting this kernel debugging natively. For live
systems, we were able to use the kernel's vmlinux file from the dbgsym
package (after mucking around for a bit with KASLR offsets) along with
/proc/kcore as a core file to inspect just about any non-local
variable on the system.

For inspecting post-mortem kdumps we found that Jeff Mahoney had
already been working on this
(https://github.com/jeffmahoney/crash-python). Kdump files are
compressed and use a different on-disk format from regular core files,
but he was able to create a new "kdump" target type to support that.
His work also included code that allowed us to load the symbols for
kernel modules with their correct offsets.

Jeff also has a python script that was able to parse out Linux's list
of task_struct structures (which represent all threads on the system
threads) and hand them to gdb. This allowed us to switch threads and
view stack traces with function arguments just as we could when using
gdb to debug a userspace program.

On top of all of this, members of the Delphix team were able to put
together some code to allow some custom gdb sub-commands (written in
python) to be piped together comparable to the way commands can be
piped together in bash. By doing this we were able to put together a
few relatively simply commands to get some really powerful debugging
output.

Currently, all of this is still in the proof-of-concept stage, but I
think both Datto (my company) and Delphix would like to look to the
next steps to get these improvements integrated upstream and
stabilized. We think these could be a huge improvement to the current
situation of debugging any code in the Linux kernel. However, there
are some sticky bits that we would like to discuss if the gdb
community is interested in these changes:

1) The kdumpfile support currently requires a few custom patches added
to gdb that allow a user to create a custom target in python. The
kdumpfile target is then implemented as a python module that calls out
to libkdumpfile (written in c). I'm not sure if this is the desired
implementation of this feature. If it is not, could we get some
pointers for how we could add this support to gdb?

2) The /proc/kcore file *looks* like a core file, but it is constantly
changing underneath us as the live system changes. When debugging code
we had issues where values that should be changing were cached and
appeared to remain static. We were able to reduce the gdb cache size
to 2 bytes (I think) by running 'set stack-cache off; set code-cache
off; set dcache size 1; set dcache line-size 2', but this still
results in (at least) the last variable you inspected being cached
until you look at something else. Is there a way we can completely
disable the dcache?

3) We aren't 100% sure where all of the new code belongs. The
ZFS-specific debugging commands we can definitely keep in the ZFS
repository, but the sub-command piping infrastructure could be useful
to anyone using gdb. We're also not really sure where the scripts that
parse out kernel structures (for things like threads and per-cpu
variables) should end up.

Please let us know if you are interested in any of these changes and
let us know what some good next steps would be.

Thanks,
Tom