Read in a crash or oops-style backtrace and access DWARF information to output the current content of the stack and registers in term of symbols, and the the crash commands to dump/pretty print them. In other words, when looking at a crash dump, answer the questions "Which variable is currently stored in $rax? What is the structure of the stack? Which variable is stored at $rsp+16?"

Status at the end of hackweek 10

The code is available on github

I didn't have the time to finish this project. It turns out that it is a lot like implementing a subset of a debugger. Currently, the code reads the information about the function parameters and variables of the topmost function in the call stack but does not read their value. Remaining TODOs are outlined in README.

It was a very interesting hackweek. I got to learn a lot about the DWARF format (and a little about ELF too). So far, it does not seem to me like there are any technical hurdles that would make the goal impossible to achieve. I think that it's a very interesting project in its implementation and very useful in its goal. Therefore I'd like to continue working on this in the future.

Status at the end of hackweek 13

I refreshed my memory about the DWARF format and the structure of the core-walk program. I extended the function that prints information about function parameters and variables to support more types (typedef, enum, bool). I still didn't get to implement the crucial location expression evaluator needed to know where to retrieve values from (register, memory).

Status at the end of hackweek 14

With Ales Novak's work to add kdump support in gdb, the need of this project for kdumps is less important. On the other hand, it is still just as needed for oops, so I've adjusted the focus. During this hackweek I restructured the program so that it doesn't output detailed information about the dwarf structures by default. The new output is instead limited to what would be useful for the user: functions, parameters, variables (and stack structure, eventually). I've added the code to get file and line number of a pc address. The location expression evaluator remains to be implemented, but it's getting there.

Looking for mad skills in:

Nothing? Add some keywords!

This project is part of:

Hack Week 10 Hack Week 13 Hack Week 14


  • about 2 years ago: bpetkov liked Kernel oops decoder
  • about 2 years ago: bchou liked Kernel oops decoder
  • about 2 years ago: ZRen liked Kernel oops decoder
  • almost 4 years ago: mkubecek liked Kernel oops decoder
  • almost 4 years ago: acho-novell joined Kernel oops decoder
  • Show History


    • alnovak
      almost 4 years ago by alnovak | Reply

      So what is your intention, Benjamin? Do you want to extend the crash DWARF parsing to read these stackframe informations, or use gdb's?

      • benjamin_poirier
        over 2 years ago by benjamin_poirier | Reply

        Neither. I am using libelf and libdwarf to access object files directly. Now that you have extended gdb to handle kdumps I will focus on oops interpretation only.

    Similar Projects

    This project is one of its kind!