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

If one wants to open compressed kernel dump (that's what our customers are sending mostly when reporting kernel panics nowadays), he has to use crash. Crash is a brilliant tool with many kernel-specific hacks, but at the same time, it has a huge functionality overlap with gdb, it is hard (even impossible in many cases) to extend it.

The whole idea is to try to abandon the crash in favor of "good old" gdb, where most of the current crash' functionality (and new functions of course) should be possible to implement using i.e. python in the distant future. Enabling gdb to open kdump is the first step towards that.

Status after HackWeek 11

Enabling the gdb to access (physical memory contents of) compressed kdump was the easiest part, I've switched to Petr Tesarik's shiny new libkdumpfile library. I've managed to map the kernel's taskstructs to gdb's threads. Backtrace (with localvariables, arguments, etc. - that's what you won't get in crash) also works, unless there are modules loaded (their debuginfo can be loaded manually to the respective modulecore addresses, but in order to access their code we'd have to have the proper virtual2physical memory mapping). What remains of the most wanted items:

• virtual2physical memory mapping
• module management
• understanding of the interesting kernel structures - but that should be done using i.e. python extensions

I'll try to make at least IBS project out of this.