來自：

https://blog.csdn.net/caijp1090/article/details/7471862

https://blog.csdn.net/gatieme/article/details/68948080

驅動程式開發的一個重大難點就是不易除錯。本文目的就是介紹驅動開發中常用的幾種直接和間接的除錯手段，它們是：

利用printk

檢視OOP訊息

利用strace

利用核心內建的hacking選項

利用ioctl方法

利用/proc 檔案系統

使用kgdb

一、利用printk

這是驅動開發中最樸實無華，同時也是最常用和有效的手段。scull驅動的main.c第338行如下，就是使用printk進行除錯的例子，這樣的例子相信大家在閱讀驅動原始碼時隨處可見。

338 //              printk(KERN_ALERT "wakeup by signal in process %d\n", current->pid);

printk的功能與我們經常在應用程式中使用的printf是一樣的，不同之處在於printk可以在列印字串前面加上核心定義的巨集，例如上面例子中的KERN_ALERT（注意：巨集與字串之間沒有逗號）。

#define KERN_EMERG "<0>"

#define KERN_ALERT "<1>"

#define KERN_CRIT "<2>"

#define KERN_ERR "<3>"

#define KERN_WARNING "<4>"

#define KERN_NOTICE "<5>"

#define KERN_INFO "<6>"

#define KERN_DEBUG "<7>"

#define DEFAULT_CONSOLE_LOGLEVEL 7

這個巨集是用來定義需要列印的字串的級別。值越小，級別越高。核心中有個引數用來控制是否將printk列印的字串輸出到控制檯（螢幕或者/sys/log/syslog日誌檔案）

# cat /proc/sys/kernel/printk
6       4       1       7

第一個6表示級別高於（小於）

因此，如果你發現在控制檯上看不到你程式中某些printk的輸出，請使用echo 8 > /proc/sys/kernel/printk來解決。

我們在複雜驅動的開發過程中，為了除錯會在原始碼中加入成百上千的printk語句。而當除錯完畢形成最終產品的時候必然會將這些printk語句刪除（為什麼？想想你自己是驅動的使用者而不是開發者吧。記住：己所不欲，勿施於人），這個工作量是不小的。最要命的是，如果我們將除錯用的printk語句刪除後，使用者又報告我們的驅動有bug，所以我們又不得不手工將這些上千條的printk語句再重新加上。oh，my god，殺了我吧。所以，我們需要一種能方便地開啟和關閉除錯資訊的手段。哪裡能找到這種手段呢？哈哈，遠在天邊，近在眼前。看看scull驅動或者leds驅動的原始碼吧！

#define LEDS_DEBUG
#undef PDEBUG             /* undef it, just in case */
#ifdef LEDS_DEBUG
    #ifdef __KERNEL__
     /* This one if debugging is on, and kernel space */
        #define PDEBUG(fmt, args…) printk( KERN_EMERG "leds: " fmt, ## args)
    #else
     /* This one for user space */
        #define PDEBUG(fmt, args…) fprintf(stderr, fmt, ## args)
    #endif
#else
    #define PDEBUG(fmt, args…) /* not debugging: nothing */
#endif
#undef PDEBUGG
#define PDEBUGG(fmt, args…) /* nothing: it’s a placeholder */

這樣一來，在開發驅動的過程中，如果想列印除錯訊息，我們就可以用PDEBUG("address of i_cdev is %p\n", inode->i_cdev);，如果不想看到該除錯訊息，就只需要簡單的將PDEBUG改為PDEBUGG即可。而當我們除錯完畢形成最終產品時，只需要簡單地將第1行註釋掉即可。

上邊那一段程式碼中的__KERNEL__是核心中定義的巨集，當我們編譯核心（包括模組）時，它會被定義。當然如果你不明白程式碼中的…和##是什麼意思的話，就請認真查閱一下gcc關於預處理部分的資料吧！如果你實在太懶不願意去查閱的話，那就充當VC工程師把上面的程式碼copy到你的程式碼中去吧。

二、檢視OOP訊息

OOP意為驚訝。當你的驅動有問題，核心不驚訝才怪：嘿！小子，你幹嗎亂來！好吧，就讓我們來看看核心是如何驚訝的。

根據faulty.c（單擊下載）編譯出faulty.ko，並 insmod faulty.ko。執行echo yang >/dev/faulty，結果核心就驚訝了。核心為什麼會驚訝呢？因為faulty驅動的write函式執行了*(int *)0 = 0，向記憶體0地址寫入，這是核心絕對不會容許的。

52 ssize_t faulty_write (struct file *filp, const char __user *buf, size_t count,
53                 loff_t *pos)
54 {
55         /* make a simple fault by dereferencing a NULL pointer */
56         *(int *)0 = 0;
57         return 0;
58 }

1 Unable to handle kernel NULL pointer dereference at virtual address 00000000
2 pgd = c3894000
3 [00000000] *pgd=33830031, *pte=00000000, *ppte=00000000
4 Internal error: Oops: 817 [#1] PREEMPT
5 Modules linked in: faulty scull
6 CPU: 0    Not tainted  (2.6.22.6 #4)
7 PC is at faulty_write+0×10/0×18 [faulty]
8 LR is at vfs_write+0xc4/0×148
9 pc : [<bf00608c>]    lr : [<c0088eb8>]    psr: a0000013
10 sp : c3871f44  ip : c3871f54  fp : c3871f50
11 r10: 4021765c  r9 : c3870000  r8 : 00000000
12 r7 : 00000004  r6 : c3871f78  r5 : 40016000  r4 : c38e5160
13 r3 : c3871f78  r2 : 00000004  r1 : 40016000  r0 : 00000000
14 Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
15 Control: c000717f  Table: 33894000  DAC: 00000015
16 Process sh (pid: 745, stack limit = 0xc3870258)
17 Stack: (0xc3871f44 to 0xc3872000)
18 1f40:          c3871f74 c3871f54 c0088eb8 bf00608c 00000004 c38e5180 c38e5160
19 1f60: c3871f78 00000000 c3871fa4 c3871f78 c0088ffc c0088e04 00000000 00000000
20 1f80: 00000000 00000004 40016000 40215730 00000004 c002c0e4 00000000 c3871fa8
21 1fa0: c002bf40 c0088fc0 00000004 40016000 00000001 40016000 00000004 00000000
22 1fc0: 00000004 40016000 40215730 00000004 00000001 00000000 4021765c 00000000
23 1fe0: 00000000 bea60964 0000266c 401adb40 60000010 00000001 00000000 00000000
24 Backtrace:
25 [<bf00607c>] (faulty_write+0×0/0×18 [faulty]) from [<c0088eb8>] (vfs_write+0xc4/0×148)
26 [<c0088df4>] (vfs_write+0×0/0×148) from [<c0088ffc>] (sys_write+0x4c/0×74)
27  r7:00000000 r6:c3871f78 r5:c38e5160 r4:c38e5180
28 [<c0088fb0>] (sys_write+0×0/0×74) from [<c002bf40>] (ret_fast_syscall+0×0/0x2c)
29  r8:c002c0e4 r7:00000004 r6:40215730 r5:40016000 r4:00000004
30 Code: e1a0c00d e92dd800 e24cb004 e3a00000 (e5800000)

1行驚訝的原因，也就是報告出錯的原因；

2-4行是OOP資訊序號；

5行是出錯時核心已載入模組；

6行是發生錯誤的CPU序號；

7-15行是發生錯誤的位置，以及當時CPU各個暫存器的值，這最有利於我們找出問題所在地；

16行是當前程序的名字及程序ID

17-23行是出錯時，棧內的內容

24-29行是棧回溯資訊，可看出直到出錯時的函式遞進呼叫關係（確保CONFIG_FRAME_POINTER被定義）

30行是出錯指令及其附近指令的機器碼，出錯指令本身在小括號中

反彙編faulty.ko（ arm-linux-objdump -D faulty.ko > faulty.dis ；cat faulty.dis）可以看到如下的語句如下：

0000007c <faulty_write>:
  7c:   e1a0c00d        mov     ip, sp
  80:   e92dd800        stmdb   sp!, {fp, ip, lr, pc}
  84:   e24cb004        sub     fp, ip, #4      ; 0×4
  88:   e3a00000        mov     r0, #0  ; 0×0
  8c:   e5800000        str     r0, [r0]
  90:   e89da800        ldmia   sp, {fp, sp, pc}

定位出錯位置以及獲取相關資訊的過程：

9 pc : [<bf00608c>]    lr : [<c0088eb8>]    psr: a0000013

25 [<bf00607c>] (faulty_write+0×0/0×18 [faulty]) from [<c0088eb8>] (vfs_write+0xc4/0×148)
26 [<c0088df4>] (vfs_write+0×0/0×148) from [<c0088ffc>] (sys_write+0x4c/0×74)

出錯程式碼是faulty_write函式中的第5條指令（(0xbf00608c-0xbf00607c)/4+1=5），該函式的首地址是0xbf00607c，該函式總共6條指令（0×18），該函式是被0xc0088eb8的前一條指令呼叫的（即：函式返回地址是0xc0088eb8。這一點可以從出錯時lr的值正好等於0xc0088eb8得到印證）。呼叫該函式的指令是vfs_write的第49條（0xc4/4=49）指令。

達到出錯處的函式呼叫流程是：write(使用者空間的系統呼叫)–>sys_write–>vfs_write–>faulty_write

OOP訊息不僅讓我定位了出錯的地方，更讓我驚喜的是，它讓我知道了一些祕密：1、gcc中fp到底有何用處？2、為什麼gcc編譯任何函式的時候，總是要把3條看上去傻傻的指令放在整個函式的最開始？3、核心和gdb是如何知道函式呼叫棧順序，並使用函式的名字而不是地址？ 4、我如何才能知道各個函式入棧的內容？哈哈，我漸漸喜歡上了讓核心驚訝，那就再看一次核心驚訝吧。

執行 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/0×140
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行，它導致入棧的r4、r5、r6、fp全部變為了0xffffffff，ip、lr的值未變，這樣一來faulty_read函式能夠成功返回到它的呼叫者——vfs_read。但是可憐的vfs_read（忠實的APTCS規則遵守者）並不知道它的r4、r5、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         /* Let’s try a buffer overflow  */
43         memset(stack_buf, 0xff, 20);
44         if (count > 4)
45                 count = 4; /* copy 4 bytes to the user */
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      ; 0×4
   c:   e24dd004        sub     sp, sp, #4      ; 0×4，這裡為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 ; 0×14
  24:   e1a00005        mov     r0, r5
  28:   ebfffffe        bl      28 <faulty_read+0×28>  //這裡在呼叫memset

  78:   e89da878        ldmia   sp, {r3, r4, r5, r6, fp, sp, pc}

這次OOP，讓我深刻地認識到：

核心能力超強，但它不是，也不可能是萬能的。所以即使你能力再強，也要和你的team member搞好關係，否則在關鍵時候你會倒黴的；

出錯的是faulty_read，vfs_read卻做了替罪羊。所以人不要被表面現象所迷惑，要深入看本質；

核心本來超級健壯，可是你寫的驅動是核心的組成部分，由於它出錯，結果整體崩盤。所以當你加入一個團隊的時候一定要告誡自己，雖然你的角色也許並不重要，但你的疏忽大意將足以令整個非常牛X的團隊崩盤。反過來說，當你是team leader的時候，在選團隊成員的時候一定要慎重、慎重、再慎重，即使他只是一個小角色。

千萬別惹堆疊，它一旦出問題，定位錯誤將會是一件非常困難的事情。所以，千萬別惹你的領導，否則你將死得很難看。

三、利用strace

有時小問題可以通過監視程式監控使用者應用程式的行為來追蹤，同時監視程式也有助於建立對驅動正確工作的信心。例如，在看了它的讀實現如何響應不同數量資料的讀請求之後，我們能夠對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 將會在螢幕上顯示如下的內容：
open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=24576, …}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 141 entries */, 4096) = 4088
[...]
getdents64(3, /* 0 entries */, 4096) = 0
close(3) = 0
[...]
fstat64(1, {st_mode=S_IFCHR|0664, st_rdev=makedev(254, 0), …}) = 0
write(1, "MAKEDEV\nadmmidi0\nadmmidi1\nadmmid"…, 4096) = 4000
write(1, "b\nptywc\nptywd\nptywe\nptywf\nptyx0\n"…, 96) = 96
write(1, "b\nptyxc\nptyxd\nptyxe\nptyxf\nptyy0\n"…, 4096) = 3904
write(1, "s17\nvcs18\nvcs19\nvcs2\nvcs20\nvcs21"…, 192) = 192
write(1, "\nvcs47\nvcs48\nvcs49\nvcs5\nvcs50\nvc"…, 673) = 673
close(1) = 0
exit_group(0) = ?
從第一個 write 呼叫看, 明顯地, 在 ls 結束檢視目標目錄後，它試圖寫 4KB。但奇怪的是，只有 4000 位元組被成功寫入, 並且操作被重複。但當我們檢視scull 中的寫實現，發現它一次最多隻允許寫一個quantum（共4000位元組），可見驅動本來就是期望部分寫。幾步之後, 所有東西清空, 程式成功退出。正是通過strace的輸出，使我們確信驅動的部分寫功能執行正確。
作為另一個例子, 讓我們讀取 scull 裝置(使用 wc scull0 命令):
[...]
open("/dev/scull0", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFCHR|0664, st_rdev=makedev(254, 0), …}) = 0
read(3, "MAKEDEV\nadmmidi0\nadmmidi1\nadmmid"…, 16384) = 4000
read(3, "b\nptywc\nptywd\nptywe\nptywf\nptyx0\n"…, 16384) = 4000
read(3, "s17\nvcs18\nvcs19\nvcs2\nvcs20\nvcs21"…, 16384) = 865
read(3, "", 16384) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), …}) = 0
write(1, "8865 /dev/scull0\n", 17) = 17
close(3) = 0
exit_group(0) = ?
如同期望的, read 一次只能獲取 4000 位元組，但是資料總量等同於前個例子寫入的。這個例子，意外的收穫是：可以肯定，wc 為快速讀進行了優化，它因此繞過了標準庫（沒有使用fscanf），而是直接一個系統呼叫以讀取更多資料。這一點，可從跟蹤到的讀的行裡看到wc一次試圖讀取16 KB的資料而確認。

四、利用核心內建的hacking選項

核心開發者在make menuconfig的Kernel hacking提供了一些核心除錯選項。這些選項有助於我們除錯驅動程式，因為當我們啟用某些除錯選項的時候，作業系統會在發現驅動執行有問題時給出一些錯誤提示資訊，而這些資訊非常有助於驅動開發者找出驅動中的問題所在。下面就舉幾個簡單例子。

先啟用如下選項：

General setup — Configure standard kernel features (for small systems) — Load all symbols for debugging/ksymoops (NEW)

Kernel hacking — Kernel debugging

Device Drivers — Generic Driver Options — Driver Core verbose debug messages

1、Kernel debugging — Spinlock and rw-lock debugging: basic checks (NEW)可以檢查到未初始化的自旋鎖

2、Kernel debugging — Mutex debugging: basic checks (NEW) 可以檢查到未初始化的訊號量

717                 //init_MUTEX(&scull_devices[i].sem);

例如，如果我們忘記了初始化scull驅動中的訊號量（將main.c的第717行註釋掉），則在open裝置scull時只會產生OOP，而沒有其它資訊提示我們有訊號量未初始化，因此此時我們很難定位問題。相反，如果啟用了上述選項，作業系統則會產生相關提示資訊，使我們知道有未初始化的訊號量或者自旋鎖。從而，我們就可以去驅動程式碼中初始化訊號量和自旋鎖的地方修正程式。

這個測試，我們的意外收穫是：訊號量的實現，其底層仍然是自旋鎖。這與我們之前的大膽推測一致。

process 751 enter scull_open
BUG: spinlock bad magic on CPU#0, sh/751
lock: c38ac1e4, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[<c002fe70>] (dump_stack+0×0/0×14) from [<c0130b5c>] (spin_bug+0×90/0xa4)
[<c0130acc>] (spin_bug+0×0/0xa4) from [<c0130b98>] (_raw_spin_lock+0×28/0×160)
r5:40000013 r4:c38ac1e4
[<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025276c>] (_spin_lock_irqsave+0x2c/0×34)
[<c0252740>] (_spin_lock_irqsave+0×0/0×34) from [<c0053d28>] (add_wait_queue_exclusive+0×24/0×50)
r5:c38ac1e4 r4:c38a1e1c
[<c0053d04>] (add_wait_queue_exclusive+0×0/0×50) from [<c024fcf0>] (__down_interruptible+0x5c/0x16c)
r5:c38a0000 r4:c38ac1dc
[<c024fc94>] (__down_interruptible+0×0/0x16c) from [<c024fb4c>] (__down_interruptible_failed+0xc/0×20)
[<bf000530>] (scull_open+0×0/0xd8 [scull]) from [<c0088eb8>] (chrdev_open+0x1b4/0x1d8)
r6:c3ef0300 r5:c38ac1fc r4:bf0045a0

3、Kernel debugging — Spinlock debugging: sleep-inside-spinlock checking (NEW) 可以檢查出驅動在獲取自旋鎖後又睡眠以及死鎖等狀況

345       ssleep(5);

87 #define usespin

例如，如果第1個程序在獲得自旋鎖的情況下睡眠（去掉main.c第345行的註釋，去掉scull.h第87行的註釋），當第2個程序試圖獲得自旋鎖時將死鎖系統。但如果啟用了上面的選項，則在死鎖前作業系統可以給出提示資訊。

process 763 enter read
semphore get, and begin sleep 5 second in process 763
BUG: scheduling while atomic: cat/0×00000001/763
[<c002fe70>] (dump_stack+0×0/0×14) from [<c024fe64>] (schedule+0×64/0×778)
[<c024fe00>] (schedule+0×0/0×778) from [<c02510a8>] (schedule_timeout+0x8c/0xbc)

process 764 enter read
BUG: spinlock cpu recursion on CPU#0, cat/764
lock: c3ae7014, .magic: dead4ead, .owner: cat/763, .owner_cpu: 0
[<c002fe70>] (dump_stack+0×0/0×14) from [<c0130b5c>] (spin_bug+0×90/0xa4)
[<c0130acc>] (spin_bug+0×0/0xa4) from [<c0130bcc>] (_raw_spin_lock+0x5c/0×160)
r5:beed2c70 r4:c3ae7014
[<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
[<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
r4:c3949520
[<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)

BUG: spinlock lockup on CPU#0, cat/764, c3ae7014
[<c002fe70>] (dump_stack+0×0/0×14) from [<c0130c94>] (_raw_spin_lock+0×124/0×160)
[<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
[<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
r4:c3949520
[<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)

4、Magic SysRq key可以在已經死鎖的情況下，列印一些有助於定位問題的資訊

魔鍵 sysrq在大部分體系上都可用，它是用PC 鍵盤上 alt 和 sysrq 鍵組合來發出的, 或者在別的平臺上使用其他特殊鍵(詳見 documentation/sysrq.txt), 在串列埠控制檯上也可用。一個第三鍵, 與這2 個一起按下, 進行許多有用的動作中的一個：

r 關閉鍵盤原始模式; 用在一個崩潰的應用程式( 例如 X 伺服器 )可能將你的鍵盤搞成一個奇怪的狀態.

k 呼叫"安全注意鍵"( SAK ) 功能. SAK 殺掉在當前控制檯的所有執行的程序, 給你一個乾淨的終端.

s 進行一個全部磁碟的緊急同步.

u umount. 試圖重新載入所有磁碟在只讀模式. 這個操作, 常常在 s 之後馬上呼叫, 可以節省大量的檔案系統檢查時間, 在系統處於嚴重麻煩時.

b boot. 立刻重啟系統. 確認先同步和重新載入磁碟.

p 列印處理器訊息.

t 列印當前任務列表.

m 列印記憶體資訊.

例如，在系統死鎖的情況下，期望能知道暫存器的值，則可以使用該魔法鍵。

SysRq : Show Regs

Pid: 764, comm:                  cat
CPU: 0    Not tainted  (2.6.22.6 #6)
PC is at _raw_spin_lock+0xbc/0×160
LR is at _raw_spin_lock+0xcc/0×160
pc : [<c0130c2c>]    lr : [<c0130c3c>]    psr: 60000013
sp : c3b11ecc  ip : c3b11e08  fp : c3b11efc
r10: c3b10000  r9 : 00000000  r8 : 055b131f
r7 : c3ae7014  r6 : 00000000  r5 : 05f1e000  r4 : 00000000
r3 : 00000000  r2 : c3b10000  r1 : 00000001  r0 : 00000001
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: c000717f  Table: 33b48000  DAC: 00000015
[<c002cdb0>] (show_regs+0×0/0x4c) from [<c015ab00>] (sysrq_handle_showregs+0×20/0×28)
r4:c0310c34
[<c015aae0>] (sysrq_handle_showregs+0×0/0×28) from [<c015ad50>] (__handle_sysrq+0xa0/0×148)
[<c015acb0>] (__handle_sysrq+0×0/0×148) from [<c015ae28>] (handle_sysrq+0×30/0×34)
[<c015adf8>] (handle_sysrq+0×0/0×34) from [<c016477c>] (s3c24xx_serial_rx_chars+0x1b0/0x2d4)
r5:00000000 r4:c03111e4
[<c01645cc>] (s3c24xx_serial_rx_chars+0×0/0x2d4) from [<c0061474>] (handle_IRQ_event+0×44/0×80)
[<c0061430>] (handle_IRQ_event+0×0/0×80) from [<c00629a8>] (handle_level_irq+0xd0/0×134)
r7:c03073e8 r6:c3e52940 r5:00000046 r4:c03073bc
[<c00628d8>] (handle_level_irq+0×0/0×134) from [<c0038118>] (s3c_irq_demux_uart+0×50/0×90)
r7:00000000 r6:00000046 r5:00000001 r4:c03073bc
[<c00380c8>] (s3c_irq_demux_uart+0×0/0×90) from [<c003816c>] (s3c_irq_demux_uart0+0×14/0×18)
r6:c0336650 r5:0000002c r4:c0306cd4
[<c0038158>] (s3c_irq_demux_uart0+0×0/0×18) from [<c002b044>] (asm_do_IRQ+0×44/0x5c)
[<c002b000>] (asm_do_IRQ+0×0/0x5c) from [<c002ba78>] (__irq_svc+0×38/0xb0)
Exception stack(0xc3b11e84 to 0xc3b11ecc)
1e80:          00000001 00000001 c3b10000 00000000 00000000 05f1e000 00000000 
1ea0: c3ae7014 055b131f 00000000 c3b10000 c3b11efc c3b11e08 c3b11ecc c0130c3c 
1ec0: c0130c2c 60000013 ffffffff                                              
r7:00000002 r6:10000000 r5:f0000000 r4:ffffffff
[<c0130b70>] (_raw_spin_lock+0×0/0×160) from [<c025273c>] (_spin_lock+0×20/0×24)
[<c025271c>] (_spin_lock+0×0/0×24) from [<bf000610>] (scull_read+0×64/0×210 [scull])
r4:c3949520
[<bf0005ac>] (scull_read+0×0/0×210 [scull]) from [<c0085eac>] (vfs_read+0xc0/0×140)
[<c0085dec>] (vfs_read+0×0/0×140) from [<c00861d0>] (sys_read+0x4c/0×74)
r7:00000000 r6:c3b11f78 r5:c3949520 r4:c3949540
[<c0086184>] (sys_read+0×0/0×74) from [<c002bf00>] (ret_fast_syscall+0×0/0x2c)
r8:c002c0a4 r7:00000003 r6:00000003 r5:beed2c70 r4:00002000

5、Debug shared IRQ handlers可用於除錯共享中斷

五、利用ioctl方法

由於驅動中的ioctl函式可以將驅動的一些資訊返回給使用者程式，也可以讓使用者程式通過ioctl系統呼叫設定一些驅動的引數。所以在驅動的開發過程中，可以擴充套件一些ioctl的命令用於傳遞和設定除錯驅動時所需各種資訊和引數，以達到除錯驅動的目的。如何在驅動中實現ioctl，請參見“驅動程式對ioctl的規範實現”一文

六、利用/proc 檔案系統

/proc檔案系統用於核心向用戶空間暴露一些核心的資訊。因此出於除錯的目的，我們可以在驅動程式碼中增加向/proc檔案系統匯出有助於監視驅動的資訊的程式碼。這樣一來，我們就可以通過檢視/proc中的相關資訊來監視和除錯驅動。如何在驅動中實現向/proc檔案系統匯出資訊，請參見《Linux Device Driver》的4.3節。

七、使用kgdb

kgdb是在核心原始碼中打用於除錯核心的補丁，然後通過相應的硬體和軟體，就可以像gdb單步除錯應用程式一樣來除錯核心（當然包括驅動）。至於kgdb如何使用，就請你google吧，實在不行，百度一下也可以。boy, wish you good luck!