Linux内核Oops调试

在嵌入式开发环境下，常会看到系统Oops，了解Oops出现时的调试方法甚为必要，结合网络上的一些资料，列举一些常用的调试方法，供参考

1。根据Oops信息结合GDB定位具休代码行

注意行：EIP is at list_del+0xa/0x61

这告诉我们，list_del函数有0x61这么大，而Oops发生在0xa处。 假如，通过查找system.map文件，我们知道list_del函数地址为c10e53cc ，因此发生Oops时EIP为：

c10e53cc + 0xa  == c10e53d6

然后用gdb查看：
# gdb /home/arc/build/linux-2.6/vmlinux
 (gdb) b *0xc10e53d6
 Breakpoint 1 at 0xc10e53d6: file /usr/src/linux-2.6.24-rc3/lib/list_debug.c, line 64.
看，gdb直接就告诉你在哪个文件、 哪一行了。gdb中还可以这样：

# gdb Sources/linux-2.6.24/vmlinux
(gdb) l *do_fork+0x1f
0xc102b7ac is in do_fork (kernel/fork.c:1385).
1380
1381    static int fork_traceflag(unsigned clone_flags)
1382    {
1383            if (clone_flags & CLONE_UNTRACED)
1384                    return 0;
1385            else if (clone_flags & CLONE_VFORK) {
1386                    if (current->ptrace & PT_TRACE_VFORK)
1387                            return PTRACE_EVENT_VFORK;
1388            } else if ((clone_flags & CSIGNAL) != SIGCHLD) {
1389                    if (current->ptrace & PT_TRACE_CLONE)
(gdb)
也可以直接知道line number。

或者：
(gdb) l *(0xffffffff8023eaf0 + 0xff)  /* 出错函数的地址加 上偏移 */

 
    Oops显示的信息中,EIP值是最为重要的，它告诉我们CPU下一条指令的指行地址，就算不能使用GDB找到发生问题的确切点，也可以参考System.map文件找到大概的出错位置，这样调试的范围大大缩小，针对性更强。

2。core dump
    所以core是指内存信息，core dump的意思也就是指当问题发生时，将当前内存信息保存下来，进而通过查找堆栈信息找出出错点，这种方法在嵌入式Linux没有用过，但ISOS操作系统中有这样的功能

3。直接打印堆栈信息

     使用通过backtrace 和backtrace_symbols 或backtrace_symbols_fd 实现当前线程的堆栈打印