1.當驅動有誤時,比如,訪問的內存地址是非法的,便會打印一大串的oops出來
1.1以LED驅動為例
將open()函數里的ioremap()屏蔽掉,直接使用物理地址的GPIOF,如下圖所示:
1.2然后編譯裝載26th_segmentfault並執行測試程序后,內核便打印了oops出來,如下圖所示:
2.接下來,我們便來分析oops:
Unable to handle kernel paging request at virtual address 56000050 //無法處理內核頁面請求的虛擬地址56000050 pgd = c3850000 [56000050] *pgd=00000000 Internal error: Oops: 5 [#1] //內部錯誤oops Modules linked in: 26th_segmentfault //表示內部錯誤發生在26th_segmentfault.ko驅動模塊里 CPU: 0 Not tainted (2.6.22.6 #2) PC is at first_drv_open+0x78/0x12c [26th_segmentfault] //PC值:程序運行成功的最后一次地址,位於first_drv_open()函數里,偏移值0x78,該函數總大小0x12c LR is at 0xc0365ed8 //LR值 /*發生錯誤時的各個寄存器值*/ pc : [<bf000078>] lr : [<c0365ed8>] psr: 80000013 sp : c3fcbe80 ip : c0365ed8 fp : c3fcbe94 r10: 00000000 r9 : c3fca000 r8 : c04df960 r7 : 00000000 r6 : 00000000 r5 : bf000de4 r4 : 00000000 r3 : 00000000 r2 : 56000050 r1 : 00000001 r0 : 00000052 Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment user Control: c000717f Table: 33850000 DAC: 00000015 Process 26th_segmentfau (pid: 813, stack limit = 0xc3fca258) //發生錯誤時,進程名稱為26th_segmentfault Stack: (0xc3fcbe80 to 0xc3fcc000) //棧信息 be80: c06d7660 c3e880c0 c3fcbebc c3fcbe98 c008d888 bf000010 00000000 c04df960 bea0: c3e880c0 c008d73c c0474e20 c3fb9534 c3fcbee4 c3fcbec0 c0089e48 c008d74c bec0: c04df960 c3fcbf04 00000003 ffffff9c c002c044 c380a000 c3fcbefc c3fcbee8 bee0: c0089f64 c0089d58 00000000 00000002 c3fcbf68 c3fcbf00 c0089fb8 c0089f40 bf00: c3fcbf04 c3fb9534 c0474e20 00000000 00000000 c3851000 00000101 00000001 bf20: 00000000 c3fca000 c04c90a8 c04c90a0 ffffffe8 c380a000 c3fcbf68 c3fcbf48 bf40: c008a16c c009fc70 00000003 00000000 c04df960 00000002 be84ce38 c3fcbf94 bf60: c3fcbf6c c008a2f4 c0089f88 00008588 be84ce84 00008718 0000877c 00000005 bf80: c002c044 4013365c c3fcbfa4 c3fcbf98 c008a3a8 c008a2b0 00000000 c3fcbfa8 bfa0: c002bea0 c008a394 be84ce84 00008718 be84ce30 00000002 be84ce38 be84ce30 bfc0: be84ce84 00008718 0000877c 00000003 00008588 00000000 4013365c be84ce58 bfe0: 00000000 be84ce28 0000266c 400c98e0 60000010 be84ce30 30002031 30002431 Backtrace: //回溯信息 [<bf000000>] (first_drv_open+0x0/0x12c [26th_segmentfault]) from [<c008d888>] (chrdev_open+0x14c/0x164) r5:c3e880c0 r4:c06d7660 [<c008d73c>] (chrdev_open+0x0/0x164) from [<c0089e48>] (__dentry_open+0x100/0x1e8) r8:c3fb9534 r7:c0474e20 r6:c008d73c r5:c3e880c0 r4:c04df960 [<c0089d48>] (__dentry_open+0x0/0x1e8) from [<c0089f64>] (nameidata_to_filp+0x34/0x48) [<c0089f30>] (nameidata_to_filp+0x0/0x48) from [<c0089fb8>] (do_filp_open+0x40/0x48) r4:00000002 [<c0089f78>] (do_filp_open+0x0/0x48) from [<c008a2f4>] (do_sys_open+0x54/0xe4) r5:be84ce38 r4:00000002 [<c008a2a0>] (do_sys_open+0x0/0xe4) from [<c008a3a8>] (sys_open+0x24/0x28) [<c008a384>] (sys_open+0x0/0x28) from [<c002bea0>] (ret_fast_syscall+0x0/0x2c) Code: bf000094 bf0000b4 bf0000d4 e5952000 (e5923000) Segmentation fault
2.1上面的回溯信息,表示了函數的整個調用過程
比如上面的回溯信息表示:
- sys_open()->do_sys_open()->do_filp_open()->nameidata_to_filp()->chrdev_open()->first_drv_open();
最終錯誤出在了first_drv_open();
若內核沒有配置回溯信息顯示,則就不會打印函數調用過程,可以修改內核的.config文件,添加:
//CONFIG_FRAME_POINTER,表示幀指針,用fp寄存器表示
內核里,就會通過fp寄存器記錄函數的運行位置,並存到棧里,然后當出問題時,從棧里調出fp寄存器,查看函數的調用關系,就可以看到回溯信息.
(PS:若不配置,也可以直接通過棧來分析函數調用過程,在下章會分析到:http://www.cnblogs.com/lifexy/p/8011966.html)
2.2而有些內核的環境不同,opps也可能不會打印出上面的:
Modules linked in: 26th_segmentfault PC is at first_drv_open+0x78/0x12c [26th_segmentfault]
這些相關信息, 只打印PC值,就根本無法知道,到底是驅動模塊出的問題,還是內核自帶的函數出的問題?
所以oops里的最重要內容還是這一段: pc : [<bf000078>]
2.3那么如何來確定,該PC值地址位於內核的函數,還是我們裝載的驅動模塊?
答:
可以在內核源碼的根目錄下通過的“vi System.map”來查看,該文件保存了內核里所有(符號、函數)的虛擬地址映射,比如下圖的內核函數root_dev_setup():
通過vi命令的:0和:$命令行,可以看到內核的虛擬地址是c0004000~c03cebf4
所以,pc值bf000078為的驅動模塊的地址值
2.4當有多個驅動裝載時,又如何區分PC值是哪個驅動的函數的地址值?
答:通過/proc/kallsyms來查看:
#cat /proc/kallsyms //(kernel all symbols)查看所有的內核標號(包括內核函數,裝載的驅動函數,變量符號等)的地址值
或者:
#cat /proc/kallsyms> /kallsyms.txt //將地址值放入kallsyms.txt中
如下圖所示,在kallsyms.txt里,找到pc值bf000078位於26th_segmentfault驅動里first_drv_open()函數下的bf000000+0x78中
2.5然后將驅動生成反匯編:
arm-linux-objdump -D 26th_segmentfault.ko >26th_segmentfault.dis //反匯編
2.6打開反匯編:
如下圖所示,左邊是kallsyms.txt,右邊是26th_segmentfault.dis反匯編
顯然pc值bf000078,就位於反匯編的78地址處:
Disassembly of section .text: //.text段起始地址為0x00 00000000 <first_drv_open>: 38: e59fc0e8 ldr ip, [pc, #232]; 128 <.text+0x128> //ip=.text段+0x128里的內容 ... ... 50: e585c000 str ip, [r5] //r5=.text段+0x128里的內容 ... ... 74: e5952000 ldr r2, [r5] //r2=.text段+0x128里的內容 78: e5923000 ldr r3, [r2] // r3=.text段+0x128里的內容 7c: e3c33c3f bic r3, r3, #16128 ;0x3f00 //清除0x56000050的bit8~13 ... ... 128: 56000050 undefined //.text段+0x128里的內容=0x56000050
從上面看到,78地址處,主要是將0x56000050(r2)地址里的內容放入r3中.
而0x56000050是個物理地址,在linux眼中便是個非法地址,所以出錯
並找到出錯地方位於first_drv_open ()函數下:
3.若發生錯誤的驅動位於內核的地址值時
3.1還是以26th_segmentfault.c為例,首先加入內核:
#cp 26th_segmentfault.c /linux-2.6.22.6/drivers/char/ //將有問題的驅動復制到字符驅動目錄下
#vi Makefile
添加:
obj-y += 26th_segmentfault.o //y:將該驅動放入內核中
3.2然后make uImage裝載新內核后,再運行測試程序,便會打印出opps信息
3.3在內核源碼的根目錄下通過:
# arm-none-linux-gnueabi-objdump -D vmlinux > vmlinux.dis
將整個內核反匯編, vmlinux:未壓縮的內核
3.4 vi vmlinux.dis，然后通過oops信息的PC值直接來查找地址即可
接下來下章便通過棧信息來分析函數調用過程:http://www.cnblogs.com/lifexy/p/8011966.html