轉自:http://blog.csdn.net/lichangc/article/details/43272457html
驅動程序開發的一個重大難點就是不易調試。本文目的就是介紹驅動開發中經常使用的幾種直接和間接的調試手段,它們是:node
這是驅動開發中最樸實無華,同時也是最經常使用和有效的手段。scull驅動的main.c第338行以下,就是使用printk進行調試的例子,這樣的例子相信你們在閱讀驅動源碼時隨處可見。linux
338 // printk(KERN_ALERT "wakeup by signal in process %d\n", current->pid);程序員
printk的功能與咱們常常在應用程序中使用的printf是同樣的,不一樣之處在於printk能夠在打印字符串前面加上內核定義的宏,例如上面例子中的KERN_ALERT(注意:宏與字符串之間沒有逗號)。安全
這個宏是用來定義須要打印的字符串的級別。值越小,級別越高。內核中有個參數用來控制是否將printk打印的字符串輸出到控制檯(屏幕或者/sys/log/syslog日誌文件)服務器
1 # cat /proc/sys/kernel/printk 2 6 4 1 7
第一個6表示級別高於(小於)6的消息纔會被輸出到控制檯,第二個4表示若是調用printk時沒有指定消息級別(宏)則消息的級別爲4,第三個1表示接受的最高(最小)級別是1,第四個7表示系統啓動時第一個6原來的初值是7。ide
所以,若是你發如今控制檯上看不到你程序中某些printk的輸出,請使用echo 8 > /proc/sys/kernel/printk來解決。函數
咱們在複雜驅動的開發過程當中,爲了調試會在源碼中加入成百上千的printk語句。而當調試完畢造成最終產品的時候必然會將這些printk語句刪除(爲何?想一想你本身是驅動的使用者而不是開發者吧。記住:己所不欲,勿施於人),這個工做量是不小的。最要命的是,若是咱們將調試用的printk語句刪除後,用戶又報告咱們的驅動有bug,因此咱們又不得不手工將這些上千條的printk語句再從新加上。oh,my god,殺了我吧。因此,咱們須要一種能方便地打開和關閉調試信息的手段。哪裏能找到這種手段呢?哈哈,遠在天邊,近在眼前。看看scull驅動或者leds驅動的源代碼吧!工具
1 #define LEDS_DEBUG 2 #undef PDEBUG 3 #ifdef LEDS_DEBUG 4 #ifdef __KERNEL__ 5 6 #define PDEBUG(fmt, args...) printk( KERN_EMERG "leds: " fmt, ## args) 7 #else 8 9 #define PDEBUG(fmt, args...) fprintf(stderr, fmt, ## args) 10 #endif 11 #else 12 #define PDEBUG(fmt, args...) 13 #endif 14 #undef PDEBUGG 15 #define PDEBUGG(fmt, args...)
這樣一來,在開發驅動的過程當中,若是想打印調試消息,咱們就能夠用PDEBUG("address of i_cdev is %p\n", inode->i_cdev);,若是不想看到該調試消息,就只須要簡單的將PDEBUG改成PDEBUGG便可。而當咱們調試完畢造成最終產品時,只須要簡單地將第1行註釋掉便可。oop
上邊那一段代碼中的__KERNEL__是內核中定義的宏,當咱們編譯內核(包括模塊)時,它會被定義。固然若是你不明白代碼中的...和##是什麼意思的話,就請認真查閱一下gcc關於預處理部分的資料吧!若是你實在太懶不肯意去查閱的話,那就充當VC工程師把上面的代碼copy到你的代碼中去吧。
ooP意爲驚訝。當你的驅動有問題,內核不驚訝纔怪:嘿!小子,你幹嘛亂來!好吧,就讓咱們來看看內核是如何驚訝的。
根據faulty.c(單擊下載)編譯出faulty.ko,並 insmod faulty.ko。執行echo yang >/dev/faulty,結果內核就驚訝了。內核爲何會驚訝呢?由於faulty驅動的write函數執行了*(int *)0 = 0,向內存0地址寫入,這是內核絕對不會允許的。
1 ssize_t faulty_write (struct file *filp, const char __user *buf, size_t count, 2 loff_t *pos) 3 { 4 *(int *)0 = 0; 5 return 0; 6 }
反彙編faulty.ko( arm-linux-objdump -D faulty.ko > faulty.dis; cat faulty.dis)能夠看到以下的語句以下:
1 0000007c <faulty_write>: 2 e1a0c00d mov ip, sp 3 e92dd800 stmdb sp!, {fp, ip, lr, pc} 4 e24cb004 sub fp, ip, #4 ; 0x4 5 e3a00000 mov r0, #0 ; 0x0 6 e5800000 str r0, [r0] 7 e89da800 ldmia sp, {fp, sp, pc}
定位出錯位置以及獲取相關信息的過程:
1 9 pc : [<bf00608c>] lr : [<c0088eb8>] psr: a0000013 2 25 [<bf00607c>] (faulty_write+0x0/0x18 [faulty]) from [<c0088eb8>] (vfs_write+0xc4/0x148) 3 26 [<c0088df4>] (vfs_write+0x0/0x148) from [<c0088ffc>] (sys_write+0x4c/0x74)
出錯代碼是faulty_write函數中的第5條指令((0xbf00608c-0xbf00607c)/4+1=5),該函數的首地址是0xbf00607c,該函數總共6條指令(0x18),該函數是被0xc0088eb8的前一條指令調用的(即:函數返回地址是0xc0088eb8。這一點能夠從出錯時lr的值正好等於0xc0088eb8獲得印證)。調用該函數的指令是vfs_write的第49條(0xc4/4=49)指令。
達到出錯處的函數調用流程是:write(用戶空間的系統調用)-->sys_write-->vfs_write-->faulty_write
OOP消息不只讓我定位了出錯的地方,更讓我驚喜的是,它讓我知道了一些祕密:
一、gcc中fp到底有何用處?
二、爲何gcc編譯任何函數的時候,老是要把3條看上去傻傻的指令放在整個函數的最開始?
三、內核和gdb是如何知道函數調用棧順序,並使用函數的名字而不是地址?
四、我如何才能知道各個函數入棧的內容?哈哈,我漸漸喜歡上了讓內核驚訝,那就再看一次內核驚訝吧。
執行 cat /dev/faulty,內核又再一次驚訝!
1 Unable to handle kernel NULL pointer dereference at virtual address 0000000b 2 pgd = c3a88000 3 [0000000b] *pgd=33a79031, *pte=00000000, *ppte=00000000 4 Internal error: Oops: 13 [#2] PREEMPT 5 Modules linked in: faulty 6 CPU: 0 Not tainted (2.6.22.6 #4) 7 PC is at vfs_read+0xe0/0x140 8 LR is at 0xffffffff 9 pc : [<c0088c84>] lr : [<ffffffff>] psr: 20000013 10 sp : c38d9f54 ip : 0000001c fp : ffffffff 11 r10: 00000001 r9 : c38d8000 r8 : 00000000 12 r7 : 00000004 r6 : ffffffff r5 : ffffffff r4 : ffffffff 13 r3 : ffffffff r2 : 00000000 r1 : c38d9f38 r0 : 00000004 14 Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user 15 Control: c000717f Table: 33a88000 DAC: 00000015 16 Process cat (pid: 767, stack limit = 0xc38d8258) 17 Stack: (0xc38d9f54 to 0xc38da000) 18 9f40: 00002000 c3c105a0 c3c10580 19 9f60: c38d9f78 00000000 c38d9fa4 c38d9f78 c0088f88 c0088bb4 00000000 00000000 20 9f80: 00000000 00002000 bef07c80 00000003 00000003 c002c0e4 00000000 c38d9fa8 21 9fa0: c002bf40 c0088f4c 00002000 bef07c80 00000003 bef07c80 00002000 00000000 22 9fc0: 00002000 bef07c80 00000003 00000000 00000000 00000001 00000001 00000003 23 9fe0: 00000000 bef07c6c 0000266c 401adab0 60000010 00000003 00000000 00000000 24 Backtrace: invalid frame pointer 0xffffffff 25 Code: ebffff86 e3500000 e1a07000 da000015 (e594500c) 26 Segmentation fault
不過此次驚訝卻使人大爲不解。OOP居然說出錯的地方在vfs_read(要知道它但是大拿們千錘百煉的內核代碼),這怎麼可能?哈哈,萬能的內核也不能追蹤函數調用棧了,這是爲何?其實問題出在faulty_read的43行,它致使入棧的r四、r五、r六、fp所有變爲了0xffffffff,ip、lr的值未變,這樣一來faulty_read函數可以成功返回到它的調用者——vfs_read。可是可憐的vfs_read(忠實的APTCS規則遵照者)並不知道它的r四、r五、r6已經被萬惡的faulty_read改變,這樣下去vfs_read命運就可想而知了——必死無疑!雖然內核頗有能力,但缺乏了正確的fp的幫助,它也沒法追蹤函數調用棧。
36 ssize_t faulty_read(struct file *filp, char __user *buf, 37 size_t count, loff_t *pos) 38 { 39 int ret; 40 char stack_buf[4]; 41 42 43 memset(stack_buf, 0xff, 20); 44 if (count > 4) 45 count = 4; 46 ret = copy_to_user(buf, stack_buf, count); 47 if (!ret) 48 return count; 49 return ret; 50 }
00000000 <faulty_read>: 0: e1a0c00d mov ip, sp 4: e92dd870 stmdb sp!, {r4, r5, r6, fp, ip, lr, pc} 8: e24cb004 sub fp, ip, #4 ; 0x4 c: e24dd004 sub sp, sp, #4 ; 0x4,這裏爲stack_buf[]在棧上分配1個字的空間,局部變量ret使用寄存器存儲,所以就不在棧上分配空間了 10: e24b501c sub r5, fp, #28 ; 0x1c 14: e1a04001 mov r4, r1 18: e1a06002 mov r6, r2 1c: e3a010ff mov r1, #255 ; 0xff 20: e3a02014 mov r2, #20 ; 0x14 24: e1a00005 mov r0, r5 28: ebfffffe bl 28 <faulty_read+0x28> //這裏在調用memset 78: e89da878 ldmia sp, {r3, r4, r5, r6, fp, sp, pc}
此次OOP,讓我深入地認識到:
有時小問題能夠經過監視程序監控用戶應用程序的行爲來追蹤,同時監視程序也有助於創建對驅動正確工做的信心。例如,在看了它的讀實現如何響應不一樣數量數據的讀請求以後,咱們可以對scull正在正確運行感到有信心。
有幾個方法來監視用戶空間程序運行。你能夠運行一個調試器來單步過它的函數,增長打印語句,或者在 strace 下運行程序。這裏,咱們將討論最後一個技術,由於當真正目的是檢查內核代碼時,它是最有用的。
strace 命令是一個有力工具,它能顯示全部的用戶空間程序發出的系統調用。它不只顯示調用,還以符號形式顯示調用的參數和返回值。當一個系統調用失敗, 錯誤的符號值(例如, ENOMEM)和對應的字串(Out of memory) 都顯示。strace 有不少命令行選項,其中最有用的是 -t 來顯示每一個調用執行的時間,-T 來顯示調用中花費的時間,-e 來限制被跟蹤調用的類型(例如strace –eread,write ls表示只監控read和write調用),以及-o 來重定向輸出到一個文件。缺省狀況下,strace 打印調用信息到 stderr。
strace 從內核自身獲取信息。這意味着能夠跟蹤一個程序,無論它是否帶有調試支持編譯(對 gcc 是 -g 選項)以及無論它是否被strip過。此外,你也能夠追蹤一個正在運行中的進程,這相似於調試器鏈接到一個運行中的進程並控制它。
跟蹤信息經常使用來支持發給應用程序開發者的故障報告,可是對內核程序員也是頗有價值的。咱們已經看到驅動代碼運行如何響應系統調用,strace 容許咱們檢查每一個調用的輸入和輸出數據的一致性。
例如,運行命令 strace ls /dev > /dev/scull0 將會在屏幕上顯示以下的內容:
1 open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 2 fstat64(3, {st_mode=S_IFDIR|0755, st_size=24576, ...}) = 0 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 4 getdents64(3, , 4096) = 4088 5 [...] 6 getdents64(3, , 4096) = 0 7 close(3) = 0 8 [...] 9 fstat64(1, {st_mode=S_IFCHR|0664, st_rdev=makedev(254, 0), ...}) = 0 10 write(1, "MAKEDEV\nadmmidi0\nadmmidi1\nadmmid"..., 4096) = 4000 11 write(1, "b\nptywc\nptywd\nptywe\nptywf\nptyx0\n"..., 96) = 96 12 write(1, "b\nptyxc\nptyxd\nptyxe\nptyxf\nptyy0\n"..., 4096) = 3904 13 write(1, "s17\nvcs18\nvcs19\nvcs2\nvcs20\nvcs21"..., 192) = 192 14 write(1, "\nvcs47\nvcs48\nvcs49\nvcs5\nvcs50\nvc"..., 673) = 673 15 close(1) = 0 16 exit_group(0) = ?
第一個 write 調用看, 明顯地, 在 ls 結束查看目標目錄後,它試圖寫 4KB。但奇怪的是,只有 4000 字節被成功寫入, 而且操做被重複。但當咱們查看scull 中的寫實現,發現它一次最多隻容許寫一個quantum(共4000字節),可見驅動原本就是指望部分寫。幾步以後, 全部東西清空, 程序成功退出。正是經過strace的輸出,使咱們確信驅動的部分寫功能運行正確。
做爲另外一個例子, 讓咱們讀取 scull 設備(使用 wc scull0 命令):
1 [...] 2 open("/dev/scull0", O_RDONLY|O_LARGEFILE) = 3 3 fstat64(3, {st_mode=S_IFCHR|0664, st_rdev=makedev(254, 0), ...}) = 0 4 read(3, "MAKEDEV\nadmmidi0\nadmmidi1\nadmmid"..., 16384) = 4000 5 read(3, "b\nptywc\nptywd\nptywe\nptywf\nptyx0\n"..., 16384) = 4000 6 read(3, "s17\nvcs18\nvcs19\nvcs2\nvcs20\nvcs21"..., 16384) = 865 7 read(3, "", 16384) = 0 8 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 9 write(1, "8865 /dev/scull0\n", 17) = 17 10 close(3) = 0 11 exit_group(0) = ?
如同指望的, read 一次只能獲取 4000 字節,可是數據總量等同於前個例子寫入的。這個例子,意外的收穫是:能夠確定,wc 爲快速讀進行了優化,它所以繞過了標準庫(沒有使用fscanf),而是直接一個系統調用以讀取更多數據。這一點,可從跟蹤到的讀的行裏看到wc一次試圖讀取16 KB的數據而確認。
內核開發者在make menuconfig的Kernel hacking提供了一些內核調試選項。這些選項有助於咱們調試驅動程序,由於當咱們啓用某些調試選項的時候,操做系統會在發現驅動運行有問題時給出一些錯誤提示信息,而這些信息很是有助於驅動開發者找出驅動中的問題所在。下面就舉幾個簡單例子。
先啓用以下選項:
一、Kernel debugging -- Spinlock and rw-lock debugging: basic checks (NEW)能夠檢查到未初始化的自旋鎖
二、Kernel debugging -- Mutex debugging: basic checks (NEW) 能夠檢查到未初始化的信號量
717 //init_MUTEX(&scull_devices[i].sem);
例如,若是咱們忘記了初始化scull驅動中的信號量(將main.c的第717行註釋掉),則在open設備scull時只會產生OOP,而沒有其它信息提示咱們有信號量未初始化,所以此時咱們很難定位問題。相反,若是啓用了上述選項,操做系統則會產生相關提示信息,使咱們知道有未初始化的信號量或者自旋鎖。從而,咱們就能夠去驅動代碼中初始化信號量和自旋鎖的地方修正程序。
這個測試,咱們的意外收穫是:信號量的實現,其底層仍然是自旋鎖。這與咱們以前的大膽推測一致。
1 process 751 enter scull_open 2 BUG: spinlock bad magic on CPU#0, sh/751 3 lock: c38ac1e4, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 4 [<c002fe70>] (dump_stack+0x0/0x14) from [<c0130b5c>] (spin_bug+0x90/0xa4) 5 [<c0130acc>] (spin_bug+0x0/0xa4) from [<c0130b98>] (_raw_spin_lock+0x28/0x160) 6 r5:40000013 r4:c38ac1e4 7 [<c0130b70>] (_raw_spin_lock+0x0/0x160) from [<c025276c>] (_spin_lock_irqsave+0x2c/0x34) 8 [<c0252740>] (_spin_lock_irqsave+0x0/0x34) from [<c0053d28>] (add_wait_queue_exclusive+0x24/0x50) 9 r5:c38ac1e4 r4:c38a1e1c 10 [<c0053d04>] (add_wait_queue_exclusive+0x0/0x50) from [<c024fcf0>] (__down_interruptible+0x5c/0x16c) 11 r5:c38a0000 r4:c38ac1dc 12 [<c024fc94>] (__down_interruptible+0x0/0x16c) from [<c024fb4c>] (__down_interruptible_failed+0xc/0x20) 13 [<bf000530>] (scull_open+0x0/0xd8 [scull]) from [<c0088eb8>] (chrdev_open+0x1b4/0x1d8) 14 r6:c3ef0300 r5:c38ac1fc r4:bf0045a0 15 3、Kernel debugging -- Spinlock debugging: sleep-inside-spinlock checking (NEW) 能夠檢查出驅動在獲取自旋鎖後又睡眠以及死鎖等情況 16 345 ssleep(5); 17 87 #define usespin
例如,若是第1個進程在得到自旋鎖的狀況下睡眠(去掉main.c第345行的註釋,去掉scull.h第87行的註釋),當第2個進程試圖得到自旋鎖時將死鎖系統。但若是啓用了上面的選項,則在死鎖前操做系統能夠給出提示信息。
1 process 764 enter read 2 BUG: spinlock cpu recursion on CPU#0, cat/764 3 lock: c3ae7014, .magic: dead4ead, .owner: cat/763, .owner_cpu: 0 4 [<c002fe70>] (dump_stack+0x0/0x14) from [<c0130b5c>] (spin_bug+0x90/0xa4) 5 [<c0130acc>] (spin_bug+0x0/0xa4) from [<c0130bcc>] (_raw_spin_lock+0x5c/0x160) 6 r5:beed2c70 r4:c3ae7014 7 [<c0130b70>] (_raw_spin_lock+0x0/0x160) from [<c025273c>] (_spin_lock+0x20/0x24) 8 [<c025271c>] (_spin_lock+0x0/0x24) from [<bf000610>] (scull_read+0x64/0x210 [scull]) 9 r4:c3949520 10 [<bf0005ac>] (scull_read+0x0/0x210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0x140)
1 BUG: spinlock lockup on CPU#0, cat/764, c3ae7014 2 [<c002fe70>] (dump_stack+0x0/0x14) from [<c0130c94>] (_raw_spin_lock+0x124/0x160) 3 [<c0130b70>] (_raw_spin_lock+0x0/0x160) from [<c025273c>] (_spin_lock+0x20/0x24) 4 [<c025271c>] (_spin_lock+0x0/0x24) from [<bf000610>] (scull_read+0x64/0x210 [scull]) 5 r4:c3949520 6 [<bf0005ac>] (scull_read+0x0/0x210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0x140)
四、Magic SysRq key能夠在已經死鎖的狀況下,打印一些有助於定位問題的信息
魔鍵 sysrq在大部分體系上均可用,它是用PC 鍵盤上 alt 和 sysrq 鍵組合來發出的, 或者在別的平臺上使用其餘特殊鍵(詳見 documentation/sysrq.txt), 在串口控制檯上也可用。一個第三鍵, 與這2 個一塊兒按下, 進行許多有用的動做中的一個:
例如,在系統死鎖的狀況下,指望能知道寄存器的值,則可使用該魔法鍵。
1 SysRq : Show Regs 2 Pid: 764, comm: cat 3 CPU: 0 Not tainted (2.6.22.6 #6) 4 PC is at _raw_spin_lock+0xbc/0x160 5 LR is at _raw_spin_lock+0xcc/0x160 6 pc : [<c0130c2c>] lr : [<c0130c3c>] psr: 60000013 7 sp : c3b11ecc ip : c3b11e08 fp : c3b11efc 8 r10: c3b10000 r9 : 00000000 r8 : 055b131f 9 r7 : c3ae7014 r6 : 00000000 r5 : 05f1e000 r4 : 00000000 10 r3 : 00000000 r2 : c3b10000 r1 : 00000001 r0 : 00000001 11 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user 12 Control: c000717f Table: 33b48000 DAC: 00000015 13 [<c002cdb0>] (show_regs+0x0/0x4c) from [<c015ab00>] (sysrq_handle_showregs+0x20/0x28) 14 r4:c0310c34 15 [<c015aae0>] (sysrq_handle_showregs+0x0/0x28) from [<c015ad50>] (__handle_sysrq+0xa0/0x148) 16 [<c015acb0>] (__handle_sysrq+0x0/0x148) from [<c015ae28>] (handle_sysrq+0x30/0x34) 17 [<c015adf8>] (handle_sysrq+0x0/0x34) from [<c016477c>] (s3c24xx_serial_rx_chars+0x1b0/0x2d4) 18 r5:00000000 r4:c03111e4 19 [<c01645cc>] (s3c24xx_serial_rx_chars+0x0/0x2d4) from [<c0061474>] (handle_IRQ_event+0x44/0x80) 20 [<c0061430>] (handle_IRQ_event+0x0/0x80) from [<c00629a8>] (handle_level_irq+0xd0/0x134) 21 r7:c03073e8 r6:c3e52940 r5:00000046 r4:c03073bc 22 [<c00628d8>] (handle_level_irq+0x0/0x134) from [<c0038118>] (s3c_irq_demux_uart+0x50/0x90) 23 r7:00000000 r6:00000046 r5:00000001 r4:c03073bc 24 [<c00380c8>] (s3c_irq_demux_uart+0x0/0x90) from [<c003816c>] (s3c_irq_demux_uart0+0x14/0x18) 25 r6:c0336650 r5:0000002c r4:c0306cd4 26 [<c0038158>] (s3c_irq_demux_uart0+0x0/0x18) from [<c002b044>] (asm_do_IRQ+0x44/0x5c) 27 [<c002b000>] (asm_do_IRQ+0x0/0x5c) from [<c002ba78>] (__irq_svc+0x38/0xb0) 28 Exception stack(0xc3b11e84 to 0xc3b11ecc) 29 1e80: 00000001 00000001 c3b10000 00000000 00000000 05f1e000 00000000 30 1ea0: c3ae7014 055b131f 00000000 c3b10000 c3b11efc c3b11e08 c3b11ecc c0130c3c 31 1ec0: c0130c2c 60000013 ffffffff 32 r7:00000002 r6:10000000 r5:f0000000 r4:ffffffff 33 [<c0130b70>] (_raw_spin_lock+0x0/0x160) from [<c025273c>] (_spin_lock+0x20/0x24) 34 [<c025271c>] (_spin_lock+0x0/0x24) from [<bf000610>] (scull_read+0x64/0x210 [scull]) 35 r4:c3949520 36 [<bf0005ac>] (scull_read+0x0/0x210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0x140) 37 [<c0085dec>] (vfs_read+0x0/0x140) from [<c00861d0>] (sys_read+0x4c/0x74) 38 r7:00000000 r6:c3b11f78 r5:c3949520 r4:c3949540 39 [<c0086184>] (sys_read+0x0/0x74) from [<c002bf00>] (ret_fast_syscall+0x0/0x2c) 40 r8:c002c0a4 r7:00000003 r6:00000003 r5:beed2c70 r4:00002000
五、Debug shared IRQ handlers可用於調試共享中斷
因爲驅動中的ioctl函數能夠將驅動的一些信息返回給用戶程序,也可讓用戶程序經過ioctl系統調用設置一些驅動的參數。因此在驅動的開發過程當中,能夠擴展一些ioctl的命令用於傳遞和設置調試驅動時所需各類信息和參數,以達到調試驅動的目的。如何在驅動中實現ioctl,請參見「驅動程序對ioctl的規範實現」一文
/proc文件系統用於內核向用戶空間暴露一些內核的信息。所以出於調試的目的,咱們能夠在驅動代碼中增長向/proc文件系統導出有助於監視驅動的信息的代碼。這樣一來,咱們就能夠經過查看/proc中的相關信息來監視和調試驅動。如何在驅動中實現向/proc文件系統導出信息,請參見《Linux Device Driver》的4.3節。
kgdb是在內核源碼中打用於調試內核的補丁,而後經過相應的硬件和軟件,就能夠像gdb單步調試應用程序同樣來調試內核(固然包括驅動)。至於kgdb如何使用,就請你google吧,實在不行,百度一下也能夠。boy, wish you good luck!
http://blog.sina.com.cn/s/blog_3e4774e30101ac91.html