关于内核反汇编，同时显示源文件

写了个platform架构的UART测试驱动，在卸载的时候出了问题,驱动卸载不掉，感觉很奇怪，

用户空间使用的rmmod最终会调用kernel/module.c 中的 SYSCALL_DEFINE2(delete_module, const char __user*, name_user, unsigned int, flags)

1、按找lsmod显示的模块名查找模块

         mod = find_module(name);
        if (!mod) {
        ret = -ENOENT;
        printk("lccdandeion we cant find mod\n");
        goto out;}

2、检查是否有模块依赖于本模块

         if (!list_empty(&mod->modules_which_use_me)) {
        /* Other modules depend on us: get rid of them first. */
        printk("lccdandeion there are modules using me\n");
        ret = -EWOULDBLOCK;
        goto out;
    }
3、检查模块是否存活

         /* If it has an init func, it must have an exit func to unload */
    if (mod->init && !mod->exit)
    {
        forced = try_force_unload(flags);
        if (!forced) {
            /* This module can't be removed */
            ret = -EBUSY;
            goto out;
        }
    }
4、若用户空间传递的参数要求强制卸载则卸载（内核编译时要选中可强制卸载模块），检查模块的引用计数是否为零（不为零，则一直等待到引用计数为零）

        /* Never wait if forced. */
    if (!forced && module_refcount(mod) != 0)
    {
        printk("lccdandlion wait for zero refcount\n");
        wait_for_zero_refcount(mod);
        printk("lccdandelion wait end\n");
    }
5、

    /* Final destruction now noone is using it. */
    if (mod->exit != NULL)
    {
        printk("lccdandeion did we blocked\n");
        mod->exit();
    }
写的UART驱动测试在调用mod->exit()崩溃。

面对panic，我们该如何定位问题

1、Google

2、利用panic信息、反汇编内核

对于2：

源码树顶层下的Makefile 中KBUILD_CFLAGS ：= -Wall -Wundef -Wstrict-prototype ....

添加 KBUILD_CFLAGS := -g -Wall -Wunde -Wstrict-prototype

这样生成的内核将含有调试信息，611内核源码不支持gdb，但是我们可以反汇编，

unicore32-linux-objdump -Dz -S vmlinux >> linux.dump

根据panic信息可以定位到最终报错时的几个函数调用路径，在函数中打桩，一步步的定位问题，虽然611有些封闭，但是内核核心出现的问题google一般都可以查到。

 

虽然问题解决了，但是panic的信息还是怪怪的，panic时，pc值竟然不再内核空间中？？？？！！！！