This is the mail archive of the
mailing list for the GDB project.
Re: Linux kernel debugging and other features
- From: Philipp Rudo <prudo at linux dot ibm dot com>
- To: Thomas Caputi <tcaputi at datto dot com>
- Cc: gdb at sourceware dot org, Florian Weimer <fweimer at redhat dot com>, Dave Anderson <anderson at redhat dot com>
- Date: Tue, 14 May 2019 09:49:21 -0400
- Subject: Re: Linux kernel debugging and other features
- References: <CAF2oFs9T0NZTAu5hdvjtTYfJT70t1MSj=5kVnmz9BUD8bpUM_Q@mail.gmail.com>
that really sounds like a great piece of code you are having. A little back I
worked at a similar project with focus on dump debugging on s390 .
Unfortunately the project never made it beyond the prototype...
My approach back then was to include everything directly into GDB without
using any python scripts whatsoever. All in all it worked quite well and
allowed walking the task_struct and converting them to gdb threads,
create backtrace of kernel threads and loading kernel modules as 'shared
However there where also some drawbacks. As it was directly included into gdb
only elf dumps could be inspected. The virtual address translation was a
little bit shaky as addresses in gdb are represented by simple ulongs without
any information about the address space. Furthermore I concentrated on
post-mortem dumps, exactly for the problems you describe below...
Anyway, I'm thrilled to have a look at your code and see how you are solving
I'm not sure if Florian's suggestion to add the code to crash is the proper
way. Crash is based on a 7.6 gdb. So it's already quite old and probably
doesn't have all the functionality you need. Nevertheless I CCed Dave
Anderson, the crash maintainer. I guess he's interested in this discussion as
Back when I was working on my project I didn't have the impression that there
was any fundamental objections in adding the feature to gdb. It basically
depends on your implementation to solve the problem. So for the next step, I'd
suggest you simply post your patches to the gdb-patches list and we take the
discussion from there.
On Mon, 13 May 2019 16:19:49 -0400
Thomas Caputi <email@example.com> wrote:
> 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
> 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.