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 "crashgui", but this is not as extensible as it could be. It may be useful to have the possibility to look at certain crash outputs using just web browser.
At least these functions would be useful:
look up a symbol
list a disassembly of a function
struct xxx [yyy]
get memory dump
It would certainly be fancy to be able to click from dis -l to line:number, but don't be too greedy.
The solution would consist of writing a crash extension with functionality of waiting for being called, fetching certain outputs and packing them into web-readable format (JSON probably) and sending them over a socket. Interface of this extension is yet to be determined.
Another part is that this could be joined with managing multiple running crash sessions, preparing debuginfo files and so on. So one could type for example:
http://l3slave:1234/866555/2
to get to second vmcore of 866555.
Status at the end of Hackweek 10:
The project is in status of working proof of concept - it enables you to:
view kernel log
click at functions in Call trace and view their disassembly (and navigate by mouse within jumps & calls in it)
view structure declarations (and the nested structures too)
from declarations, jump to structure instances in memory
If anybody is interested, I'll put running demo somewhere. Example screen looks like this:
Though it was real fun, I've had too high expectations of what crash is able to offer. I've ended up with just passing crash/gdb outputs to JavaScript frontend.
Looking for hackers with the skills:
This project is part of:
Hack Week 10
Comments
Be the first to comment!
Similar Projects
Symbol Relations by hli
Description
There are tools to build function call graphs based on parsing source code, for example, cscope
.
This project aims to achieve a similar goal by directly parsing the disasembly (i.e. objdump) of a compiled binary. The assembly code is what the CPU sees, therefore more "direct". This may be useful in certain scenarios, such as gdb/crash debugging.
Detailed description and Demos can be found in the README file:
Supports x86 for now (because my customers only use x86 machines), but support for other architectures can be added easily.
Tested with python3.6
Goals
Any comments are welcome.
Resources
https://github.com/lhb-cafe/SymbolRelations
symrellib.py: mplements the symbol relation graph and the disassembly parser
symrel_tracer*.py: implements tracing (-t option)
symrel.py: "cli parser"