linux裝置驅動第四篇：從如何定位oops的程式碼談驅動調試方法

標籤：linux驅動   驅動崩潰定位   oops定位程式碼   

上一篇我們大概聊了如何寫一個簡單的字元裝置驅動，我們不是神，寫代碼肯定會出現問題，我們需要在編寫代碼的過程中不斷調試。在普通的c應用程式中，我們經常使用printf來輸出資訊，或者使用gdb來偵錯工具，那麼驅動程式如何調試呢？我們知道在偵錯工具時經常遇到的問題就是野指標或者數組越界帶來的問題，在應用程式中運行這種程式就會報segmentation fault的錯誤，而由於驅動程式的特殊性，出現此類情況後往往會直接造成系統宕機，並會拋出oops資訊。那麼我們如何來分析oops資訊呢，甚至根據oops資訊來定位具體的出錯的程式碼呢？下面就根據一個簡單的執行個體來說明如何調試驅動程式。

如何根據oops定位程式碼

我們借用linux裝置驅動第二篇：構造和運行模組裡面的hello world程式來示範出錯的情況，含有錯誤碼的hello world如下：

#include <linux/init.h>#include <linux/module.h>MODULE_LICENSE("Dual BSD/GPL");static int hello_init(void){        char *p = NULL;        memcpy(p, "test", 4);        printk(KERN_ALERT "Hello, world\n");        return 0;}static void hello_exit(void){        printk(KERN_ALERT "Goodbye, cruel world\n");}module_init(hello_init);module_exit(hello_exit);

Makefile檔案如下：

ifneq ($(KERNELRELEASE),)obj-m := helloworld.oelseKERNELDIR ?= /lib/modules/$(shell uname -r)/buildPWD := $(shell pwd)default:        $(MAKE) -C $(KERNELDIR) M=$(PWD) modulesendifclean:        rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c .tmp_versions modules.order  Module.symvers

很明顯，以上代碼的第8行是一個null 指標錯誤。insmod後會出現下面的oops資訊：

[  459.516441] BUG: unable to handle kernel NULL pointer dereference at           (null)[  459.516445] <span style="color:#ff0000;">IP: [<ffffffffc061400d>] hello_init+0xd/0x30 [helloworld]</span>[  459.516448] PGD 0 [  459.516450] Oops: 0002 [#1] SMP [  459.516452] Modules linked in: helloworld(OE+) vmw_vsock_vmci_transport vsock coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel vmw_balloon snd_ens1371 aes_x86_64 lrw snd_ac97_codec gf128mul glue_helper ablk_helper cryptd ac97_bus gameport snd_pcm serio_raw snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer vmwgfx btusb ttm snd drm_kms_helper drm soundcore shpchp vmw_vmci i2c_piix4 rfcomm bnep bluetooth 6lowpan_iphc parport_pc ppdev mac_hid lp parport hid_generic usbhid hid psmouse ahci libahci floppy e1000 vmw_pvscsi vmxnet3 mptspi mptscsih mptbase scsi_transport_spi pata_acpi [last unloaded: helloworld][  459.516476] CPU: 0 PID: 4531 Comm: insmod Tainted: G           OE 3.16.0-33-generic #44~14.04.1-Ubuntu[  459.516478] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014[  459.516479] task: ffff88003821f010 ti: ffff880038fa0000 task.ti: ffff880038fa0000[  459.516480] RIP: 0010:[<ffffffffc061400d>]  [<ffffffffc061400d>] hello_init+0xd/0x30 [helloworld][  459.516483] RSP: 0018:ffff880038fa3d40  EFLAGS: 00010246[  459.516484] RAX: ffff88000c31d901 RBX: ffffffff81c1a020 RCX: 000000000004b29f[  459.516485] RDX: 000000000004b29e RSI: 0000000000000017 RDI: ffffffffc0615024[  459.516485] RBP: ffff880038fa3db8 R08: 0000000000015e80 R09: ffff88003d615e80[  459.516486] R10: ffffea000030c740 R11: ffffffff81002138 R12: ffff88000c31d0c0[  459.516487] R13: 0000000000000000 R14: ffffffffc0614000 R15: ffffffffc0616000[  459.516488] FS:  00007f8a6fa86740(0000) GS:ffff88003d600000(0000) knlGS:0000000000000000[  459.516489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[  459.516490] CR2: 0000000000000000 CR3: 0000000038760000 CR4: 00000000003407f0[  459.516522] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[  459.516524] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[  459.516524] Stack:[  459.516537]  ffff880038fa3db8 ffffffff81002144 0000000000000001 0000000000000001[  459.516540]  0000000000000001 ffff880028ab5040 0000000000000001 ffff880038fa3da0[  459.516541]  ffffffff8119d0b2 ffffffffc0616018 00000000bd1141ac ffffffffc0616018[  459.516543] Call Trace:[  459.516548]  [<ffffffff81002144>] ? do_one_initcall+0xd4/0x210[  459.516550]  [<ffffffff8119d0b2>] ? __vunmap+0xb2/0x100[  459.516554]  [<ffffffff810ed9b1>] load_module+0x13c1/0x1b80[  459.516557]  [<ffffffff810e9560>] ? store_uevent+0x40/0x40[  459.516560]  [<ffffffff810ee2e6>] SyS_finit_module+0x86/0xb0[  459.516563]  [<ffffffff8176be6d>] system_call_fastpath+0x1a/0x1f[  459.516564] Code: <c7> 04 25 00 00 00 00 74 65 73 74 31 c0 48 89 e5 e8 a2 86 14 c1 31 [  459.516573] RIP  [<ffffffffc061400d>] hello_init+0xd/0x30 [helloworld][  459.516575]  RSP <ffff880038fa3d40>[  459.516576] CR2: 0000000000000000[  459.516578] ---[ end trace 7c52cc8624b7ea60 ]---

下面簡單分析下oops資訊的內容。

由BUG: unable to handle kernel NULL pointer dereference at           (null)知道出錯的原因是使用了null 指標。標紅的部分確定了具體出錯的函數。Modules linked in: helloworld表明了引起oops問題的具體模組。call trace列出了函數的調用資訊。這些資訊中其中標紅的部分是最有用的，我們可以根據其資訊找到具體出錯的程式碼。下面就來說下，如何定位到具體出錯的程式碼。

第一步我們需要使用objdump把編譯產生的bin檔案反組譯碼，我們這裡就是helloworld.o，如下命令把反組譯碼資訊儲存到err.txt檔案中：

objdump helloworld.o -D > err.txt

err.txt內容如下：

helloworld.o:     file format elf64-x86-64Disassembly of section .text:<span style="color:#ff0000;">0000000000000000 <init_module>:</span>   0:e8 00 00 00 00       callq  5 <init_module+0x5>   5:55                   push   %rbp   6:48 c7 c7 00 00 00 00 mov    $0x0,%rdi   d:c7 04 25 00 00 00 00 movl   $0x74736574,0x0  14:74 65 73 74   18:31 c0                xor    %eax,%eax  1a:48 89 e5             mov    %rsp,%rbp  1d:e8 00 00 00 00       callq  22 <init_module+0x22>  22:31 c0                xor    %eax,%eax  24:5d                   pop    %rbp  25:c3                   retq     26:66 2e 0f 1f 84 00 00 nopw   %cs:0x0(%rax,%rax,1)  2d:00 00 00 0000000000000030 <cleanup_module>:  30:e8 00 00 00 00       callq  35 <cleanup_module+0x5>  35:55                   push   %rbp  36:48 c7 c7 00 00 00 00 mov    $0x0,%rdi  3d:31 c0                xor    %eax,%eax  3f:48 89 e5             mov    %rsp,%rbp  42:e8 00 00 00 00       callq  47 <cleanup_module+0x17>  47:5d                   pop    %rbp  48:c3                   retq   Disassembly of section .rodata.str1.1:0000000000000000 <.rodata.str1.1>:   0:01 31                add    %esi,(%rcx)   2:48                   rex.W   3:65                   gs   4:6c                   insb   (%dx),%es:(%rdi)   5:6c                   insb   (%dx),%es:(%rdi)   6:6f                   outsl  %ds:(%rsi),(%dx)   7:2c 20                sub    $0x20,%al   9:77 6f                ja     7a <cleanup_module+0x4a>   b:72 6c                jb     79 <cleanup_module+0x49>   d:64 0a 00             or     %fs:(%rax),%al  10:01 31                add    %esi,(%rcx)  12:47 6f                rex.RXB outsl %ds:(%rsi),(%dx)  14:6f                   outsl  %ds:(%rsi),(%dx)  15:64                   fs  16:62                   (bad)    17:79 65                jns    7e <cleanup_module+0x4e>  19:2c 20                sub    $0x20,%al  1b:63 72 75             movslq 0x75(%rdx),%esi  1e:65                   gs  1f:6c                   insb   (%dx),%es:(%rdi)  20:20 77 6f             and    %dh,0x6f(%rdi)  23:72 6c                jb     91 <cleanup_module+0x61>  25:64 0a 00             or     %fs:(%rax),%alDisassembly of section .modinfo:0000000000000000 <__UNIQUE_ID_license0>:   0:6c                   insb   (%dx),%es:(%rdi)   1:69 63 65 6e 73 65 3d imul   $0x3d65736e,0x65(%rbx),%esp   8:44 75 61             rex.R jne 6c <cleanup_module+0x3c>   b:6c                   insb   (%dx),%es:(%rdi)   c:20 42 53             and    %al,0x53(%rdx)   f:44 2f                rex.R (bad)   11:47 50                rex.RXB push %r8  13:4c                   rex.WR...Disassembly of section .comment:0000000000000000 <.comment>:   0:00 47 43             add    %al,0x43(%rdi)   3:43 3a 20             rex.XB cmp (%r8),%spl   6:28 55 62             sub    %dl,0x62(%rbp)   9:75 6e                jne    79 <cleanup_module+0x49>   b:74 75                je     82 <cleanup_module+0x52>   d:20 34 2e             and    %dh,(%rsi,%rbp,1)  10:38 2e                cmp    %ch,(%rsi)  12:32 2d 31 39 75 62    xor    0x62753931(%rip),%ch        # 62753949 <cleanup_module+0x62753919>  18:75 6e                jne    88 <cleanup_module+0x58>  1a:74 75                je     91 <cleanup_module+0x61>  1c:31 29                xor    %ebp,(%rcx)  1e:20 34 2e             and    %dh,(%rsi,%rbp,1)  21:38 2e                cmp    %ch,(%rsi)  23:32 00                xor    (%rax),%alDisassembly of section __mcount_loc:0000000000000000 <__mcount_loc>:

由oops資訊我們知道出錯的地方是hello_init的地址位移0xd。而有dump資訊知道，hello_init的地址即init_module的地址，因為hello_init即本模組的初始化入口，如果在其他函數中出錯，dump資訊中就會有相應符號的地址。由此我們得到出錯的地址是0xd，下一步我們就可以使用addr2line來定位具體的程式碼：

addr2line -C -f -e helloworld.o d

此命令就可以得到行號了。以上就是通過oops資訊來定位驅動崩潰的行號。

其他調試手段

以上就是通過oops資訊來擷取具體的導致崩潰的程式碼，這種情況都是用在遇到比較嚴重的錯誤導致核心掛掉的情況下使用的，另外比較常用的調試手段就是使用printk來輸出列印資訊。printk的使用方法類似printf，只是要注意一下列印層級，詳細介紹在linux裝置驅動第二篇：構造和運行模組中已有描述，另外需要注意的是大量使用printk會嚴重拖慢系統，所以使用過程中也要注意。

以上兩種調試手段是我工作中最常用的，還有一些其他的調試手段，例如使用/proc檔案系統，使用trace等使用者空間程式，使用gdb，kgdb等，這些調試手段一般不太容易使用或者不太方便使用，所以這裡就不在介紹了。

介紹完驅動的調試方法後，下一篇會介紹下linux驅動的並發與競態，歡迎關注。

第一時間獲得部落格更新提醒，以及更多技術資訊分享，歡迎關注個人公眾平台:程式員互動聯盟(coder_online)，掃一掃下方二維碼或搜尋號coder_online即可關注,我們可以線上交流。

 

linux裝置驅動第四篇：從如何定位oops的程式碼談驅動調試方法