转自：http://blog.chinaunix.net/uid-26403844-id-3361770.html
http://blog.csdn.net/ryfjx6/article/details/7064854
刚刚接触内核，在调试过程中用printk打印信息当然是直接有效的办法，但当我们不知到一个函数或者一个模块到底在哪里出了问题时我们可以利用dump_stack有效的找到问题的根源，下面只是简单的给出了使用方法。
我在自己的主机上试了一下dump_stack()
Makefile文件
点击(此处)折叠或打开
- obj-m := hello.o
- KERNELBUILD :=/lib/modules/$(shell uname -r)/build
- default:
- make -C $(KERNELBUILD) M=$(shell pwd) modules
- clean:
- rm -rf *.o *.ko *.mod.c .*.cmd *.markers *.order *.symvers .tmp_versions
hello.c文件
点击(此处)折叠或打开
- #include <linux/module.h>
- #include <linux/init.h>
- #include <linux/kprobes.h>
- #include <asm/traps.h>
- MODULE_LICENSE("Dual BSD/GPL");
- static int __init hello_init(void)
- {
- printk(KERN_ALERT "dump_stack start\n");
- dump_stack();
- printk(KERN_ALERT "dump_stack over\n");
- return 0;
- }
- static void __exit hello_exit(void)
- {
- printk(KERN_ALERT "test module\n");
- }
- module_init(hello_init);
- module_exit(hello_exit);
注意使用dump_stack（）要加上这两个头文件
点击(此处)折叠或打开
- #include <linux/kprobes.h>
- #include <asm/traps.h>
然后make得到hello.ko
在运行insmod hello.ko把模块插入内核
运行dmesg
[ 3719.352022] usb 1-8: new high speed USB device number 11 using ehci_hcd
[ 4266.252826] usb 1-8: USB disconnect, device number 11
[ 5246.942980] dump_stack start
[ 5246.942985] Pid: 3438, comm: insmod Not tainted 3.0.0-21-generic #35-Ubuntu
[ 5246.942987] Call Trace:
[ 5246.942993] [] hello_init+0x17/0x1000 [hello]
[ 5246.942999] [] do_one_initcall+0x42/0x180
[ 5246.943003] [] sys_init_module+0xbe/0x230
[ 5246.943006] [] system_call_fastpath+0x16/0x1b
[ 5246.943008] dump_stack over
打出运行这个模块时调用的函数
删除模rmmod hello
补充：
Android.mk文件
点击(此处)折叠或打开
- obj-m := hello.o
- #hello-objs := hello-world.o
- KVERSION := $(ANDROID_PRODUCT_OUT)/obj/KERNEL_OBJ
- all:
- make ARCH=arm CROSS_COMPILE=arm-eabi- -C $(KVERSION) M=$(PWD) modules
- clean:
- make -C $(KVERSION) M=$(PWD) clean
在android编译环境下编译，编译出来的.ko文件可以在手机中insmod
http://blog.csdn.net/sqhxhg/article/details/6369190
一、dump_stack(堆栈转储）作用：主要用于内核调试，打印内核堆栈段信息。
二、使用前便已内核时：使用前，先在内核配置中把kernel debug选上：
make menuconfig:
kernel hacking-->
kernel debug
三、arch/x86/kernel/dumpstack.c
void dump_stack(void){
unsigned long bp=0;
unsigned long stack;
#ifdef CONFIG_FRAME_POINTER
if(!bp)
get_bp(bp);
#endif
printk("pid:%d,comm:%20s %s %s %.*s/n",current->pid,current->comm,print_tainted(),init_utsname()->release,(int)strcspn(init_utsname()->version,init_utsname()->version);
show_trace(NULL,NULL&stack,bp);
}
dump_stack不准确的原因分析
kernel panic后打印的堆栈信息是调用dump_stack函数获得的。而dump_stack的原理是遍历堆栈，把所有可能是内核函数的内容找出来，并打印对应的函数。因为函数调用时会把下一条指令的地址放到堆栈中。所以只要找到这些return address，就可以找到这些return address所在函数，进而打印函数的调用关系。
但是dump_stack可能不准确，可能的原因有三：
1.所有这些可以找到的函数地址，存在/proc/kallsyms中。它并不包括内核中所有的函数，而只包括内核中stext~etext和sinittext~einittext范围的函数，及模块中的函数。详细可参考scripts/kallsyms.c
2.一些函数在编译时进行了优化，把call指令优化为jmp指令，这样在调用时就不会把return address放到堆栈，导致dump_stack时在堆栈中找不到对应的信息。
3.堆栈中可能有一些数值，它们不是return address，但是在内核函数地址的范围里，这些数值会被误认为return address从而打印出错误的调用关系。