In Linux, usually, kernel crashes with so-called Oops report.
This Oops report includes lots of useful information for debugging.
Therefore, I have seen lots of developer suffering from analyzing register, memory and stack dump in the report.
To analyze dumped information, memory information should be matched with source code.
But, this is not easy process.
So, I want to introduce the way to do this easily.
Main concept is, we can make tool to parse Oops report and pass these to debugging tool.
Here is introduction of my case.
I uses TRACE32 software - ARM simulator for debugging tool.
What I did is, implementing simple Perl script that parses Oops report and make cmm file that set register and memory information given by the report.
For example, auto generated cmm file is like this.
R.S cpsr 0x20000013 R.S r0 0x0 R.S r1 0x0 ... D.S 0xc035a248 %long 0xe3a02000 D.S 0xc035a24c %long 0xe3a03020 ...
It's time to use TRACE32 PowerView for ARM to analyze the report.
Launching t32marm with simulator mode -> Loading issued 'vmlinux' -> Runnig auto-generated cmm script
Finally, I can see stack frame with local variables and interpreted memory information by virtue of T32.
I'm sorry not to share parsing tool - Perl script - due to ... as you know, something like legal issue... (I hate this.)
I hope this post is helpful for others...
'Domain > Kernel' 카테고리의 다른 글
| Ext4 에 대한 분석 <Analysis regarding Ext4> (1) | 2012.06.12 |
|---|---|
| [Kernel] How to know KBUILD_MODNAME of each files. (0) | 2012.01.09 |
| [Kernel] SMP and IRQ - case (2011-Sep) (0) | 2011.09.23 |
| [Kernel] Potential bug for using jiffies - ex. schedule_timeout() - at Linux kernel. (0) | 2011.08.18 |
| [Kernel] Debugging/Controlling GPIO at user space on Linux Kernel. (0) | 2011.06.22 |