alnovak

Examining vmcore with crash (very) often means to look at multiple outputs at once, which in console enviroment simply is not easily achievable. Since last hackweek, there is a

The goal of the project is making the gdb able to open compressed kernel dump - access its memory contents at the very least.

The disassembly in gdb is not ideal. The binding with source code lines is weird (even crash, which does use gdb beneath, does that better), I don't see the jump targets; furthermore, there's a lot more informations hidden in the DWARF2 which may be of some interest - like which code is inlined, or which register/stack address should contain some variable.

gdb-kdump (and libkdumpfile) needs a plenty of improvements and tasks to be done. For HackWeek 13, Vlastimil chose to work on SLAB memory support, Petr, amongst other things, reorganized the libkdumpfile code and alnovak begun with libkdumpfile's ppc64 support. Our status in 4/5 of HackWeek 13:

Our previous efforts to enable gdb to open kdumps was not received in upstream as well as we hoped for. The perhaps-acceptable way would be to extend gdb with the possibility of implementing targets in Python, then create example binding to libkdumpfile (which already got a Python binding). We've already tried that, yet it has to be tidyed up.

It's not always straightforward to open a core dump originating from customer's environment, since there's a wide variety of versions of all the binaries involved - usual workflow is to install a VM with the SP that the customer is using, enable debuginfo repositories and then follow the buildid hints that gdb is providing.