應用程式除錯

1. GDB命令列除錯

  嵌入式系統中一般在 PC 端執行 gdb 工具，原始碼也是在 PC 端，原始碼對應的可執行檔案放到開發板中執行。為此我們需要在開發板中執行 gdbserver，通過網路與 PC 端的 gdb 進行通訊。因此要想在 PC 上通過 gdb 除錯嵌入式程式，那麼需要兩個東西：gdb 和 gdbserver，其中 gdb 是執行在 PC 上的，gdbserver 需要我們移植到開發板上。

• 一般交叉編譯已經自帶了 gdb 和 gdbserver，因此可以不用移植，直接使用交叉編譯器中的 gdbserver 拷貝到開發板根檔案系統 /bin 目錄下即可。
• 如果交叉編譯器沒有自帶 gdb 和 gdbserver 那就需要自己手動編譯了(參考正點原子)
  
  【儘量保證gdb 和 gdbserver的版本一致，來自同一個交叉編譯器的版本】

具體除錯步驟：

	1.  （主機）arm-linux-gnueabihf-gcc gdbtest.c -o gdbtest -g     //編譯測試程式,注意-g 選項,"這樣編譯出來的可執行檔案才帶有除錯資訊,這一點一定要切記"
	2.  （開發板）gdbserver 192.168.2.15（主機IP）:2001 gdbtest //啟動開發板上的 gdbserver
	3.  （主機）arm-linux-gnueabihf-gdb gdbtest
		（gdb）  target remote 192.168.2.8:2001    //連線到開發板上
	4.   (開發板顯示)Remote debugging from host 192.168.2.15, port 2001  >>  連線成功

常用除錯命令:

1. l 命令(list)列印出了除錯程式的所有原始碼，如果原始碼沒有列印完的話就重複按下“l”命令，或者按下Enter鍵，gdb 除錯工具中Enter鍵表示重複上一個命令
   l 函式名(這樣就可以在對應的源函式中打斷點)  或者 l 地址

2. b 命令(break)用於設定斷點；	b + 函式名， b + 行號

3. c 命令用於執行到斷點處,輸入 c 命令程式就會執行,直到下一個斷點處

4. s 命令(step)是單步執行執行,此函式會進入到函式裡面

5. n 命令(next)也是單步執行,但是 n 命令不會進入到函式裡面

6. p 命令(print)用於列印某個變數值

7. q 命令(quit)用於退出除錯,開發板上的 gdbserver 也會停止

---

2. VSCode + gdbserver圖形化除錯

a. VSCode設定

1. 給 VScode 安裝遠端除錯外掛“Remote Development”，點選“除錯”->“新增配置”，然後
   選擇“C++(GDB/LLDB)”選項
2. 會在當前資料夾新建一個名為“launch.json”的檔案，此檔案會存放在.vscode 目錄下
3. 配置launch.json檔案

---

b. VScode除錯方法

1. （開發板）gdbserver 192.168.2.15（主機IP）:2001 gdbtest //啟動開發板上的 gdbserver
2. 通過 VSCode 圖形介面除錯

---

3. strace顯示使用者空間發出的系統呼叫

a. 編譯與移植

1. strace原始碼下載
2. 編譯與移植步驟

tar -xjf strace-4.5.15.tar.bz2
cd strace-4.5.15/
patch -p1 <../strace-fix-arm-bad-syscall.patch
./configure --host=arm-linux CC=arm-linux-gnueabihf-gcc        
make 
cp  strace  /usr/bin/    #複製到開發闆闆的 /usr/bin

b. 使用方法

insmod dri.ko                 
strace  -o log.txt ./test /dev/xyz0

strace  -o log.txt  rmmod dri  # 也可以直接跟蹤模組
#-t加入秒的時標, -tt為ms的時標
#具體內容檢視log.txt檔案

---

4. oops找出段錯誤發生的位置

1. 段錯誤的發生，一般是由於記憶體操作不當導致的，如指標的分配和回收
2. 棧的溢位和堆的不合理分配，通常也會導致段錯誤的發生
3. oops詳細的使用流程比較複雜

---

---

驅動程式除錯

1. 使用printk函式

  最簡單的方法是通過 printk 列印變數或者暫存器的地址和值，printk函式中可以使用附加不同的日誌級別或訊息優先順序，如下例子：

printk(KERN_DEBUG “Here is :%s: %i \n”,__FILE,__LINE__);

  上述例子中巨集KERN_DEBUG和後面的“之間沒有逗號，因為巨集實際是字串，在編譯時會由編譯器將它和後面的文字拼接在一起。在標頭檔案<linux/kern_levels.h>中定義了8種可用的日誌級別字串：

#define    KERN_EMERG    	"<0>"    /* system is unusable           */
#define    KERN_ALERT   	"<1>"    /* action must be taken immediately*/
#define    KERN_CRIT    	"<2>"    /* critical conditions    */
#define    KERN_ERR   		"<3>"    /* error conditions            */
#define    KERN_WARNING     "<4>"    /* warning conditions   */
#define    KERN_NOTICE      "<5>"    /* normal but significant condition */
#define    KERN_INFO        "<6>"    /* informational            */
#define    KERN_DEBUG    	"<7>"    /* debug-level messages   */

//未指定優先順序的預設級別定義在/kernel/printk.c中：
#define DEFAULT_MESSAGE_LOGLEVEL 4 	 /* KERN_WARNING */

  只有當優先順序的值小於console_loglevel這個整數變數的值，資訊才能顯示出來。而console_loglevel的初始值DEFAULT_CONSOLE_LOGLEVEL也定義在/kernel/printk.c中。不夠列印級別的資訊會被寫到日誌中通過 dmesg 命令來檢視。

#define DEFAULT_CONSOLE_LOGLEVEL 7 	/* anything MORE serious than KERN_DEBUG */

  通過對/proc/sys/kernel/printk的訪問來改變console_loglevel的值：

cat /proc/sys/kernel/printk			#檢視當前控制檯的列印級別
echo "新的列印級別  4    1    7" >/proc/sys/kernel/printk
#四個數字的含義：當前的loglevel、預設loglevel、最小允許的loglevel、引導時的預設loglevel

---

  自己寫一個驅動去讀寫暫存器的值，這個想法有點意思

---

2. oops檢視訊息

參考部落格：

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

  oops 意為“驚訝”，kernel的一種特殊稱呼。當你的驅動有問題，核心不驚訝才怪。

  oops根據 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-gnueabihf-objdump -D faulty.ko > 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

執行 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

  不過這次驚訝卻令人大為不解。oops竟然說出錯的地方在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}

總結：

1. 核心能力超強，但它不是，也不可能是萬能的。所以即使你能力再強，也要和你的team member搞好關係，否則在關鍵時候你會倒黴的；
2. 出錯的是faulty_read，vfs_read卻做了替罪羊。所以人不要被表面現象所迷惑，要深入看本質；
3. 核心本來超級健壯，可是你寫的驅動是核心的組成部分，由於它出錯，結果整體崩盤。所以當你加入一個團隊的時候一定要告誡自己，雖然你的角色也許並不重要，但你的疏忽大意將足以令整個非常牛X的團隊崩盤。反過來說，當你是team leader的時候，在選團隊成員的時候一定要慎重、慎重、再慎重，即使他只是一個小角色。
4. 千萬別惹堆疊，它一旦出問題，定位錯誤將會是一件非常困難的事情。所以，千萬別惹你的領導，否則你將死得很難看。

---

3. /proc 和 sysfs檔案系統，或者 ioctl 系統呼叫

  /proc 虛擬檔案系統，核心可利用它向外輸出資訊。/proc目錄下的每一個檔案都被繫結到一個核心函式，這個函式在此檔案被讀取時，動態地生成檔案的內容。典型的例子就是ps、top命令就是通過讀取/proc下的檔案來獲取他們需要的資訊。

  sysfs是一個基於ram的記憶體檔案系統（ramfs）。它提供了一種方法用於匯出核心資料結構，屬性，以及它們兩者之間的聯絡到使用者空間。

  ioctl系統呼叫會呼叫驅動的ioctl方法，我們可以通過設定不同的命名號來編寫一些測試函式，使用ioctl系統呼叫在使用者級呼叫這些函式進行除錯。

---