Linux內核調試方法總結

時間  2019-11-05
標籤 linux 內核 調試 方法 總結 欄目 Linux 简体版
原文   原文鏈接
Linux內核調試方法總結

內核開發比用戶空間開發更難的一個因素就是內核調試艱難。內核錯誤每每會致使系統宕機，很難保留出錯時的現場。調試內核的關鍵在於你的對內核的深入理解。 
php


一  調試前的準備

在調試一個bug以前，咱們所要作的準備工做有： 
html

  • 有一個被確認的bug。前端

  • 包含這個bug的內核版本號，須要分析出這個bug在哪個版本被引入，這個對於解決問題有極大的幫助。能夠採用二分查找法來逐步鎖定bug引入版本號。node

  • 對內核代碼理解越深入越好，同時還須要一點點運氣。python

  • 該bug能夠復現。若是可以找到復現規律，那麼離找到問題的緣由就不遠了。linux

  • 最小化系統。把可能產生bug的因素逐一排除掉。c++

 


二  內核中的bug

內核中的bug也是多種多樣的。它們的產生有無數的緣由，同時表象也變化無窮。從隱藏在源代碼中的錯誤到展示在目睹者面前的bug，其發做每每是一系列連鎖反應的事件纔可能出發的。雖然內核調試有必定的困難，可是經過你的努力和理解，說不定你會喜歡上這樣的挑戰。 
git


三  內核調試配置選項

學習編寫驅動程序要構建安裝本身的內核（標準主線內核）。最重要的緣由之一是：內核開發者已經創建了多項用於調試的功能。可是因爲這些功能會形成額外的輸出，並致使能降低，所以發行版廠商一般會禁止發行版內核中的調試功能。 

程序員

1  內核配置

爲了實現內核調試，在內核配置上增長了幾項：web

?
1
2
3
4
5
6
7
8
9
10
11
12
13
  Kernel hacking  --->      
[*]   Magic SysRq key 
[*]   Kernel debugging 
[*]   Debug slab memory allocations   
[*]   Spinlock and rw-lock debugging: basic checks 
[*]   Spinlock debugging:  sleep -inside-spinlock checking 
            [*]   Compile the kernel with debug info   
Device Drivers  --->   
            Generic Driver Options  ---> 
            [*]   Driver Core verbose debug messages 
General setup  ---> 
            [*]   Configure standard kernel features ( for  small systems)  ---> 
            [*]   Load all symbols  for  debugging /ksymoops

啓用選項例如： 

?
1
2
3
4
5
6
slab layer debugging（slab層調試選項） 
high-memory debugging（高端內存調試選項） 
I /O  mapping debugging（I /O 映射調試選項） 
spin-lock debugging（自旋鎖調試選項） 
stack-overflow checking（棧溢出檢查選項） 
sleep -inside-spinlock checking（自旋鎖內睡眠選項）


2  調試原子操做

從內核2.5開發，爲了檢查各種由原子操做引起的問題，內核提供了極佳的工具。 
內核提供了一個原子操做計數器，它能夠配置成，一旦在原子操做過程當中，進城進入睡眠或者作了一些可能引發睡眠的操做，就打印警告信息並提供追蹤線索。 
因此，包括在使用鎖的時候調用schedule()，正使用鎖的時候以阻塞方式請求分配內存等，各類潛在的bug都可以被探測到。 
下面這些選項能夠最大限度地利用該特性： 

?
1
2
3
4
CONFIG_PREEMPT = y 
CONFIG_DEBUG_KERNEL = y 
CONFIG_KLLSYMS = y 
CONFIG_SPINLOCK_SLEEP = y

 


四  引起bug並打印信息

1  BUG()和BUG_ON()

一些內核調用能夠用來方便標記bug，提供斷言並輸出信息。最經常使用的兩個是BUG()和BUG_ON()。


定義在<include/asm-generic>中：

 

?
1
2
3
4
5
6
7
8
9
10
#ifndef HAVE_ARCH_BUG 
#define BUG() do { 
    printk( "BUG: failure at %s:%d/%s()! " , __FILE__, __LINE__, __FUNCTION__); 
    panic( "BUG!" );    /* 引起更嚴重的錯誤，不但打印錯誤消息，並且整個系統業會掛起 */ 
}  while  (0) 
#endif 
 
#ifndef HAVE_ARCH_BUG_ON 
    #define BUG_ON(condition)  do  {  if  (unlikely(condition)) BUG(); }  while (0) 
#endif

當調用這兩個宏的時候，它們會引起OOPS，致使棧的回溯和錯誤消息的打印。 
※ 能夠把這兩個調用看成斷言使用，如：BUG_ON(bad_thing); 

2  dump_stack()

有些時候，只須要在終端上打印一下棧的回溯信息來幫助你調試。這時能夠使用dump_stack()。這個函數只在終端上打印寄存器上下文和函數的跟蹤線索。 

?
1
2
3
4
    if  (!debug_check) { 
        printk(KERN_DEBUG 「provide some information…/n」); 
        dump_stack(); 
    }

 


五  printk()

內核提供的格式化打印函數。 

1  printk函數的健壯性

      健壯性是printk最容易被接受的一個特質，幾乎在任何地方，任什麼時候候內核均可以調用它（中斷上下文、進程上下文、持有鎖時、多處理器處理時等）。 


2  printk函數脆弱之處

      在系統啓動過程當中，終端初始化以前，在某些地方是不能調用的。若是真的須要調試系統啓動過程最開始的地方，有如下方法能夠使用： 

  • 使用串口調試，將調試信息輸出到其餘終端設備。

  • 使用early_printk()，該函數在系統啓動初期就有打印能力。但它只支持部分硬件體系。



3  LOG等級

       printk和printf一個主要的區別就是前者能夠指定一個LOG等級。內核根據這個等級來判斷是否在終端上打印消息。內核把比指定等級高的全部消息顯示在終端。 
       能夠使用下面的方式指定一個LOG級別： 
printk(KERN_CRIT  「Hello, world!\n」); 
注意，第一個參數並不一個真正的參數，由於其中沒有用於分隔級別（KERN_CRIT）和格式字符的逗號（,）。KERN_CRIT自己只是一個普通的字符串（事實上，它表示的是字符串 "<2>"；表 1 列出了完整的日誌級別清單）。做爲預處理程序的一部分，C 會自動地使用一個名爲 字符串串聯 的功能將這兩個字符串組合在一塊兒。組合的結果是將日誌級別和用戶指定的格式字符串包含在一個字符串中。 

內核使用這個指定LOG級別與當前終端LOG等級console_loglevel來決定是否是向終端打印。 
下面是可以使用的LOG等級： 

?
1
2
3
4
5
6
7
8
9
#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                       */
#define KERN_DEFAULT     "<d>"   /* Use the default kernel loglevel           */

注意，若是調用者未將日誌級別提供給 printk，那麼系統就會使用默認值 KERN_WARNING "<4>"（表示只有KERN_WARNING 級別以上的日誌消息會被記錄）。因爲默認值存在變化，因此在使用時最好指定LOG級別。有LOG級別的一個好處就是咱們能夠選擇性的輸出LOG。好比平時咱們只須要打印KERN_WARNING級別以上的關鍵性LOG，可是調試的時候，咱們能夠選擇打印KERN_DEBUG等以上的詳細LOG。而這些都不須要咱們修改代碼，只須要經過命令修改默認日誌輸出級別： 

?
1
2
3
4
5
6
7
8
mtj@ubuntu :~$  cat  /proc/sys/kernel/printk
4 4 1 7
mtj@ubuntu :~$  cat  /proc/sys/kernel/printk_delay
0
mtj@ubuntu :~$  cat  /proc/sys/kernel/printk_ratelimit
5
mtj@ubuntu :~$  cat  /proc/sys/kernel/printk_ratelimit_burst
10

第一項定義了 printk API 當前使用的日誌級別。這些日誌級別表示了控制檯的日誌級別、默認消息日誌級別、最小控制檯日誌級別和默認控制檯日誌級別。printk_delay 值表示的是 printk 消息之間的延遲毫秒數（用於提升某些場景的可讀性）。注意，這裏它的值爲 0，而它是不能夠經過 /proc 設置的。printk_ratelimit 定義了消息之間容許的最小時間間隔（當前定義爲每 5 秒內的某個內核消息數）。消息數量是由 printk_ratelimit_burst 定義的（當前定義爲 10）。若是您擁有一個非正式內核而又使用有帶寬限制的控制檯設備（如經過串口）， 那麼這很是有用。注意，在內核中，速度限制是由調用者控制的，而不是在printk 中實現的。若是一個 printk 用戶要求進行速度限制，那麼該用戶就須要調用printk_ratelimit 函數。 

4  記錄緩衝區

  內核消息都被保存在一個LOG_BUF_LEN大小的環形隊列中。 
  關於LOG_BUF_LEN定義： 

?
1
  #define __LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT)
  ※ 變量CONFIG_LOG_BUF_SHIFT在內核編譯時由配置文件定義，對於i386平臺，其值定義以下（在linux26/arch/i386/defconfig中）： 

 

?
1
CONFIG_LOG_BUF_SHIFT=18

  記錄緩衝區操做： 
  ① 消息被讀出到用戶空間時，此消息就會從環形隊列中刪除。 
  ② 當消息緩衝區滿時，若是再有printk()調用時，新消息將覆蓋隊列中的老消息。 
  ③ 在讀寫環形隊列時，同步問題很容易獲得解決。 

  ※ 這個紀錄緩衝區之因此稱爲環形，是由於它的讀寫都是按照環形隊列的方式進行操做的。


5  syslogd/klogd

在標準的Linux系統上，用戶空間的守護進程klogd從紀錄緩衝區中獲取內核消息，再經過syslogd守護進程把這些消息保存在系統日誌文件中。klogd進程既能夠從/proc/kmsg文件中，也能夠經過syslog()系統調用讀取這些消息。默認狀況下，它選擇讀取/proc方式實現。klogd守護進程在消息緩衝區有新的消息以前，一直處於阻塞狀態。一旦有新的內核消息，klogd被喚醒，讀出內核消息並進行處理。默認狀況下，處理例程就是把內核消息傳給syslogd守護進程。syslogd守護進程通常把接收到的消息寫入/var/log/messages文件中。不過，仍是能夠經過/etc/syslog.conf文件來進行配置，能夠選擇其餘的輸出文件。


6  dmesg

dmesg 命令也可用於打印和控制內核環緩衝區。這個命令使用 klogctl 系統調用來讀取內核環緩衝區，並將它轉發到標準輸出（stdout）。這個命令也能夠用來清除內核環緩衝區（使用 -c 選項），設置控制檯日誌級別（-n 選項），以及定義用於讀取內核日誌消息的緩衝區大小（-s 選項）。注意，若是沒有指定緩衝區大小，那麼 dmesg 會使用 klogctl 的SYSLOG_ACTION_SIZE_BUFFER 操做肯定緩衝區大小。 

7 注意 

a) 雖然printk很健壯，可是看了源碼你就知道，這個函數的效率很低：作字符拷貝時一次只拷貝一個字節，且去調用console輸出可能還產生中斷。因此若是你的驅動在功能調試完成之後作性能測試或者發佈的時候千萬記得儘可能減小printk輸出，作到僅在出錯時輸出少許信息。不然往console輸出無用信息影響性能。 
b) printk的臨時緩存printk_buf只有1K，全部一次printk函數只能記錄<1K的信息到log buffer，而且printk使用的「ringbuffer」. 

8 內核printk和日誌系統的整體結構


9  動態調試

動態調試是經過動態的開啓和禁止某些內核代碼來獲取額外的內核信息。 
首先內核選項CONFIG_DYNAMIC_DEBUG應該被設置。全部經過pr_debug()/dev_debug()打印的信息均可以動態的顯示或不顯示。 
能夠經過簡單的查詢語句來篩選須要顯示的信息。 

－源文件名

－函數名

－行號（包括指定範圍的行號）

－模塊名

－格式化字符串

將要打印信息的格式寫入<debugfs>/dynamic_debug/control中。 

?
1
nullarbor:~  # echo 'file svcsock.c line 1603 +p' >      <debugfs>/dynamic_debug/control


參考： 
1   內核日誌及printk結構淺析 -- Tekkaman Ninja 
2   內核日誌：API 及實現 
3   printk實現分析 
4   dynamic-debug-howto.txt 

六  內存調試工具

1  MEMWATCH

MEMWATCH 由 Johan Lindh 編寫，是一個開放源代碼 C 語言內存錯誤檢測工具，您能夠本身下載它。只要在代碼中添加一個頭文件並在 gcc 語句中定義了 MEMWATCH 以後，您就能夠跟蹤程序中的內存泄漏和錯誤了。MEMWATCH 支持ANSIC，它提供結果日誌紀錄，能檢測雙重釋放（double-free）、錯誤釋放（erroneous free）、沒有釋放的內存（unfreedmemory）、溢出和下溢等等。 
清單 1. 內存樣本（test1.c）

?
1
2
3
4
5
6
7
8
9
10
11
12
13
#include <stdlib.h>
#include <stdio.h>
#include "memwatch.h"
int  main( void )
{
  char  *ptr1;
  char  *ptr2;
  ptr1 =  malloc (512);
  ptr2 =  malloc (512);
  ptr2 = ptr1;
  free (ptr2);
  free (ptr1);
}

清單 1 中的代碼將分配兩個 512 字節的內存塊，而後指向第一個內存塊的指針被設定爲指向第二個內存塊。結果，第二個內存塊的地址丟失，從而產生了內存泄漏。 
如今咱們編譯清單 1 的 memwatch.c。下面是一個 makefile 示例： 
test1

?
1
2
gcc  -DMEMWATCH -DMW_STDIO test1.c memwatch
c -o test1

當您運行 test1 程序後，它會生成一個關於泄漏的內存的報告。清單 2 展現了示例 memwatch.log 輸出文件。 

清單 2. test1 memwatch.log 文件

?
1
2
3
4
5
6
7
8
9
10
11
MEMWATCH 2.67 Copyright (C) 1992-1999 Johan Lindh
...
double - free : <4> test1.c(15), 0x80517b4 was freed from test1.c(14)
...
unfreed: <2> test1.c(11), 512 bytes at 0x80519e4
{FE FE FE FE FE FE FE FE FE FE FE FE ..............}
Memory usage statistics (global):
  N)umber of allocations made: 2
  L)argest memory usage : 1024
  T)otal of all alloc() calls: 1024
  U)nfreed bytes totals : 512

MEMWATCH 爲您顯示真正致使問題的行。若是您釋放一個已經釋放過的指針，它會告訴您。對於沒有釋放的內存也同樣。日誌結尾部分顯示統計信息，包括泄漏了多少內存，使用了多少內存，以及總共分配了多少內存。


2  YAMD

YAMD 軟件包由 Nate Eldredge 編寫，能夠查找 C 和 C++ 中動態的、與內存分配有關的問題。在撰寫本文時，YAMD 的最新版本爲 0.32。請下載 yamd-0.32.tar.gz。執行 make 命令來構建程序；而後執行 make install 命令安裝程序並設置工具。 
一旦您下載了 YAMD 以後，請在 test1.c 上使用它。請刪除 #include memwatch.h 並對 makefile 進行以下小小的修改： 
使用 YAMD 的 test1

?
1
gcc  -g test1.c -o test1

 

清單 3 展現了來自 test1 上的 YAMD 的輸出。 
清單 3. 使用 YAMD 的 test1 輸出

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
YAMD version 0.32
Executable:  /usr/src/test/yamd-0 .32 /test1
...
INFO: Normal allocation of this block
Address 0x40025e00, size 512
...
INFO: Normal allocation of this block
Address 0x40028e00, size 512
...
INFO: Normal deallocation of this block
Address 0x40025e00, size 512
...
ERROR: Multiple freeing At
free  of pointer already freed
Address 0x40025e00, size 512
...
WARNING: Memory leak
Address 0x40028e00, size 512
WARNING: Total memory leaks:
1 unfreed allocations totaling 512 bytes
*** Finished at Tue ... 10:07:15 2002
Allocated a grand total of 1024 bytes 2 allocations
Average of 512 bytes per allocation
Max bytes allocated at one  time : 1024
24 K alloced internally / 12 K mapped now / 8 K max
Virtual program size is 1416 K
End.

YAMD 顯示咱們已經釋放了內存，並且存在內存泄漏。讓咱們在清單 4 中另外一個樣本程序上試試 YAMD。 
清單 4. 內存代碼（test2.c）

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <stdlib.h>
#include <stdio.h>
int  main( void )
{
  char  *ptr1;
  char  *ptr2;
  char  *chptr;
  int  i = 1;
  ptr1 =  malloc (512);
  ptr2 =  malloc (512);
  chptr = ( char  *) malloc (512);
  for  (i; i <= 512; i++) {
    chptr[i] =  'S' ;
  } 
  ptr2 = ptr1;
  free (ptr2);
  free (ptr1);
  free (chptr);
}
您能夠使用下面的命令來啓動 YAMD： 

 

?
1
. /run-yamd  /usr/src/test/test2/test2

清單 5 顯示了在樣本程序 test2 上使用 YAMD 獲得的輸出。YAMD 告訴咱們在 for 循環中有「越界（out-of-bounds）」的狀況。 
清單 5. 使用 YAMD 的 test2 輸出

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Running  /usr/src/test/test2/test2
Temp output to  /tmp/yamd-out .1243
*********
. /run-yamd : line 101: 1248 Segmentation fault (core dumped)
YAMD version 0.32
Starting run:  /usr/src/test/test2/test2
Executable:  /usr/src/test/test2/test2
Virtual program size is 1380 K
...
INFO: Normal allocation of this block
Address 0x40025e00, size 512
...
INFO: Normal allocation of this block
Address 0x40028e00, size 512
...
INFO: Normal allocation of this block
Address 0x4002be00, size 512
ERROR: Crash
...
Tried to write address 0x4002c000
Seems to be part of this block:
Address 0x4002be00, size 512
...
Address  in  question is at offset 512 (out of bounds)
Will dump core after checking heap.
Done.

MEMWATCH 和 YAMD 都是頗有用的調試工具，它們的使用方法有所不一樣。對於 MEMWATCH，您須要添加包含文件memwatch.h 並打開兩個編譯時間標記。對於連接（link）語句，YAMD 只須要 -g 選項。 

3  Electric Fence

多數 Linux 分發版包含一個 Electric Fence 包，不過您也能夠選擇下載它。Electric Fence 是一個由 Bruce Perens 編寫的malloc()調試庫。它就在您分配內存後分配受保護的內存。若是存在 fencepost 錯誤（超過數組末尾運行），程序就會產生保護錯誤，並當即結束。經過結合 Electric Fence 和 gdb，您能夠精確地跟蹤到哪一行試圖訪問受保護內存。ElectricFence 的另外一個功能就是可以檢測內存泄漏。 

七  strace

strace 命令是一種強大的工具，它可以顯示全部由用戶空間程序發出的系統調用。strace 顯示這些調用的參數並返回符號形式的值。strace 從內核接收信息，並且不須要以任何特殊的方式來構建內核。將跟蹤信息發送到應用程序及內核開發者都頗有用。在清單 6 中，分區的一種格式有錯誤，清單顯示了 strace 的開頭部分，內容是關於調出建立文件系統操做（mkfs ）的。strace 肯定哪一個調用致使問題出現。 
清單 6. mkfs 上 strace 的開頭部分

?
1
2
3
4
5
6
7
8
9
10
11
12
13
execve( "/sbin/mkfs.jfs" , [ "mkfs.jfs" ,  "-f" ,  "/dev/test1" ], &
...
open ( "/dev/test1" , O_RDWR|O_LARGEFILE) = 4
stat64( "/dev/test1" , {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0
ioctl(4, 0x40041271, 0xbfffe128) = -1 EINVAL (Invalid argument)
write(2,  "mkfs.jfs: warning - cannot setb"  ..., 98mkfs.jfs: warning -
cannot  set  blocksize on block device  /dev/test1 : Invalid argument )
  = 98
stat64( "/dev/test1" , {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0
open ( "/dev/test1" , O_RDONLY|O_LARGEFILE) = 5
ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument)
write(2,  "mkfs.jfs: can\'t determine device" ..., ..._exit(1)
  = ?

清單 6 顯示 ioctl 調用致使用來格式化分區的 mkfs 程序失敗。 ioctl BLKGETSIZE64 失敗。（ BLKGET-SIZE64 在調用 ioctl的源代碼中定義。) BLKGETSIZE64 ioctl 將被添加到 Linux 中全部的設備，而在這裏，邏輯卷管理器還不支持它。所以，若是BLKGETSIZE64 ioctl 調用失敗，mkfs 代碼將改成調用較早的 ioctl 調用；這使得 mkfs 適用於邏輯卷管理器。 

參考： 
http://www.ibm.com/developerworks/cn/linux/sdk/l-debug/index.html#resources 

八  OOPS

OOPS（也稱 Panic）消息包含系統錯誤的細節，如 CPU 寄存器的內容等。是內核告知用戶有不幸發生的最經常使用的方式。 
內核只能發佈OOPS，這個過程包括向終端上輸出錯誤消息，輸出寄存器保存的信息，並輸出可供跟蹤的回溯線索。一般，發送完OOPS以後，內核會處於一種不穩定的狀態。 
OOPS的產生有不少可能緣由，其中包括內存訪問越界或非法的指令等。 

※ 做爲內核的開發者，一定將會常常處理OOPS。

※ OOPS中包含的重要信息，對全部體系結構的機器都是徹底相同的：寄存器上下文和回溯線索（回溯線索顯示了致使錯誤發生的函數調用鏈）。



1  ksymoops

在 Linux 中，調試系統崩潰的傳統方法是分析在發生崩潰時發送到系統控制檯的 Oops 消息。一旦您掌握了細節，就能夠將消息發送到 ksymoops 實用程序，它將試圖將代碼轉換爲指令並將堆棧值映射到內核符號。 

   ※ 如：回溯線索中的地址，會經過ksymoops轉化成名稱可見的函數名。

ksymoops須要幾項內容：Oops 消息輸出、來自正在運行的內核的 System.map 文件，還有 /proc/ksyms、vmlinux和/proc/modules。 
關於如何使用 ksymoops，內核源代碼 /usr/src/linux/Documentation/oops-tracing.txt 中或 ksymoops 手冊頁上有完整的說明能夠參考。Ksymoops 反彙編代碼部分，指出發生錯誤的指令，並顯示一個跟蹤部分代表代碼如何被調用。 

首先，將 Oops 消息保存在一個文件中以便經過 ksymoops 實用程序運行它。清單 7 顯示了由安裝 JFS 文件系統的 mount命令建立的 Oops 消息。 
清單 7. ksymoops 處理後的 Oops 消息

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  ksymoops 2.4.0 on i686 2.4.17. Options used
... 15:59:37 sfb1 kernel: Unable to handle kernel NULL pointer dereference at
virtual address 0000000
... 15:59:37 sfb1 kernel: c01588fc
... 15:59:37 sfb1 kernel: *pde = 0000000
... 15:59:37 sfb1 kernel: Oops: 0000
... 15:59:37 sfb1 kernel: CPU:    0
... 15:59:37 sfb1 kernel: EIP:    0010:[jfs_mount+60 /704 ]
... 15:59:37 sfb1 kernel: Call Trace: [jfs_read_super+287 /688 ] 
[get_sb_bdev+563 /736 ] [do_kern_mount+189 /336 ] [do_add_mount+35 /208 ]
[do_page_fault+0 /1264 ]
... 15:59:37 sfb1 kernel: Call Trace: [<c0155d4f>]...
... 15:59:37 sfb1 kernel: [<c0106e04 ...
... 15:59:37 sfb1 kernel: Code: 8b 2d 00 00 00 00 55 ...
>>EIP; c01588fc <jfs_mount+3c /2c0 > <=====
...
Trace; c0106cf3 <system_call+33 /40 >
Code; c01588fc <jfs_mount+3c /2c0 >
00000000 <_EIP>:
Code; c01588fc <jfs_mount+3c /2c0 >  <=====
   0: 8b 2d 00 00 00 00 mov 0x0,%ebp    <=====
Code; c0158902 <jfs_mount+42 /2c0 >
   6:  55 push %ebp

接下來，您要肯定 jfs_mount 中的哪一行代碼引發了這個問題。Oops 消息告訴咱們問題是由位於偏移地址 3c 的指令引發的。作這件事的辦法之一是對 jfs_mount.o 文件使用 objdump 實用程序，而後查看偏移地址 3c。Objdump 用來反彙編模塊函數，看看您的 C 源代碼會產生什麼彙編指令。清單 8 顯示了使用 objdump 後您將看到的內容，接着，咱們查看jfs_mount 的 C 代碼，能夠看到空值是第 109 行引發的。偏移地址 3c 之因此很重要，是由於 Oops 消息將該處標識爲引發問題的位置。 
清單 8. jfs_mount 的彙編程序清單

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
109 printk( "%d\n" ,*ptr);
objdump jfs_mount.o
jfs_mount.o: file format elf32-i386
Disassembly of section .text:
00000000 <jfs_mount>:
   0:55 push %ebp
  ...
  2c: e8 cf 03 00 00   call   400 <chkSuper>
  31: 89 c3       mov     %eax,%ebx
  33: 58     pop     %eax
  34: 85 db       test %ebx,%ebx
  36: 0f 85 55 02 00 00 jne 291 <jfs_mount+0x291>
  3c: 8b 2d 00 00 00 00 mov 0x0,%ebp << problem line above
  42: 55 push %ebp

 


2  kallsyms

開發版2.5內核引入了kallsyms特性，它能夠經過定義CONFIG_KALLSYMS編譯選項啓用。該選項能夠載入內核鏡像所對應的內存地址的符號名稱（即函數名），因此內核能夠打印解碼以後的跟蹤線索。相應，解碼OOPS也再也不須要System.map和ksymoops工具了。另外， 
這樣作，會使內核變大些，由於地址對應符號名稱必須始終駐留在內核所在內存上。 

?
1
2
3
4
5
6
#cat /proc/kallsyms 
c0100240   T    _stext 
c0100240   t    run_init_process 
c0100240   T      stext 
c0100269   t    init 
     …


 

3  Kdump

3.1  Kdump 的基本概念

3.1.1  什麼是 kexec ？

Kexec 是實現 kdump 機制的關鍵，它包括 2 個組成部分：一是內核空間的系統調用 kexec_load，負責在生產內核（production kernel 或 first kernel）啓動時將捕獲內核（capture kernel 或 sencond kernel）加載到指定地址。二是用戶空間的工具 kexec-tools，他將捕獲內核的地址傳遞給生產內核，從而在系統崩潰的時候可以找到捕獲內核的地址並運行。沒有 kexec 就沒有 kdump。先有 kexec 實現了在一個內核中能夠啓動另外一個內核，才讓 kdump 有了用武之地。kexec 原來的目的是爲了節省 kernel 開發人員重啓系統的時間，誰能想到這個「偷懶」的技術卻孕育了最成功的內存轉存機制呢？

3.1.2  什麼是 kdump ？

Kdump 的概念出如今 2005 左右，是迄今爲止最可靠的內核轉存機制，已經被主要的 linux™ 廠商選用。kdump是一種先進的基於 kexec 的內核崩潰轉儲機制。當系統崩潰時，kdump 使用 kexec 啓動到第二個內核。第二個內核一般叫作捕獲內核，以很小內存啓動以捕獲轉儲鏡像。第一個內核保留了內存的一部分給第二內核啓動用。因爲 kdump 利用 kexec 啓動捕獲內核，繞過了 BIOS，因此第一個內核的內存得以保留。這是內核崩潰轉儲的本質。

kdump 須要兩個不一樣目的的內核，生產內核和捕獲內核。生產內核是捕獲內核服務的對像。捕獲內核會在生產內核崩潰時啓動起來，與相應的 ramdisk 一塊兒組建一個微環境，用以對生產內核下的內存進行收集和轉存。

3.1.3  如何使用 kdump

構建系統和 dump-capture 內核，此操做有 2 種方式可選：

1）構建一個單獨的自定義轉儲捕獲內核以捕獲內核轉儲；

2） 或者將系統內核自己做爲轉儲捕獲內核，這就不須要構建一個單獨的轉儲捕獲內核。

方法（2）只能用於可支持可重定位內核的體系結構上；目前 i386，x86_64，ppc64 和 ia64 體系結構支持可重定位內核。構建一個可重定位內核使得不須要構建第二個內核就能夠捕獲轉儲。可是可能有時想構建一個自定義轉儲捕獲內核以知足特定要求。

3.1.4  如何訪問捕獲內存

在內核崩潰以前全部關於核心映像的必要信息都用 ELF 格式編碼並存儲在保留的內存區域中。ELF 頭所在的物理地址被做爲命令行參數（fcorehdr=）傳遞給新啓動的轉儲內核。

在 i386 體系結構上，啓動的時候須要使用物理內存開始的 640K，而無論操做系統內核轉載在何處。所以，這個640K 的區域在從新啓動第二個內核的時候由 kexec 備份。

在第二個內核中，「前一個系統的內存」能夠經過兩種方式訪問：

1） 經過 /dev/oldmem 這個設備接口。

一個「捕捉」設備能夠使用「raw」（裸的）方式 「讀」這個設備文件並寫出到文件。這是關於內存的 「裸」的數據轉儲，同時這些分析 / 捕捉工具應該足夠「智能」從而能夠知道從哪裏能夠獲得正確的信息。ELF 文件頭（經過命令行參數傳遞過來的 elfcorehdr）可能會有幫助。

2） 經過 /proc/vmcore。

這個方式是將轉儲輸出爲一個 ELF 格式的文件，而且能夠使用一些文件拷貝命令（好比 cp，scp 等）將信息讀出來。同時，gdb 能夠在獲得的轉儲文件上作一些調試（有限的）。這種方式保證了內存中的頁面都以正確的途徑被保存 ( 注意內存開始的 640K 被從新映射了 )。

3.1.5  kdump 的優點

1） 高可靠性

崩潰轉儲數據可從一個新啓動內核的上下文中獲取，而不是從已經崩潰內核的上下文。

2） 多版本支持

LKCD(Linux Kernel Crash Dump)，netdump，diskdump 已被歸入 LDPs(Linux Documen-tation Project) 內核。SUSE 和 RedHat 都對 kdump 有技術支持。

 

3.2  Kdump 實現流程

圖 1. RHEL6.2 執行流程 

                     圖 1. RHEL6.2 執行流程

圖 2. sles11 執行流程 

                                      圖 2. sles11 執行流程

 

3.3  配置 kdump

3.3.1  安裝軟件包和實用程序

Kdump 用到的各類工具都在 kexec-tools 中。kernel-debuginfo 則是用來分析 vmcore 文件。從 rhel5 開始，kexec-tools 已被默認安裝在發行版。而 novell 也在 sles10 發行版中把 kdump 集成進來。因此若是使用的是rhel5 和 sles10 以後的發行版，那就省去了安裝 kexec-tools 的步驟。而若是須要調試 kdump 生成的 vmcore文件，則須要手動安裝 kernel-debuginfo 包。檢查安裝包操做：


3.3.2  參數相關設置 uli13lp1:/ # rpm -qa|grep kexec 
 kexec-tools-2.0.0-53.43.10 
 uli13lp1:/ # rpm -qa 'kernel*debuginfo*'
 kernel-default-debuginfo-3.0.13-0.27.1 
 kernel-ppc64-debuginfo-3.0.13-0.27.1

系統內核設置選項和轉儲捕獲內核配置選擇在《使用 Crash 工具分析 Linux dump 文件》一文中已有說明，在此再也不贅述。僅列出內核引導參數設置以及配置文件設置。


1） 修改內核引導參數，爲啓動捕獲內核預留內存

經過下面的方法來配置 kdump 使用的內存大小。添加啓動參數"crashkernel=Y@X"，這裏，Y 是爲 kdump 捕捉內核保留的內存，X 是保留部份內存的開始位置。

  • 對於 i386 和 x86_64, 編輯 /etc/grub.conf, 在內核行的最後添加"crashkernel=128M" 。

  • 對於 ppc64，在 /etc/yaboot.conf 最後添加"crashkernel=128M"。

在 ia64, 編輯 /etc/elilo.conf，添加"crashkernel=256M"到內核行。

2） kdump 配置文件

kdump 的配置文件是 /etc/kdump.conf（RHEL6.2）；/etc/sysconfig/kdump(SLES11 sp2)。每一個文件頭部都有選項說明，能夠根據使用需求設置相應的選項。

3.3.3  啓動 kdump 服務

在設置了預留內存後，須要重啓機器，不然 kdump 是不可以使用的。啓動 kdump 服務：

Rhel6.2：

 # chkconfig kdump on 
 # service kdump status  
  Kdump is operational  
 # service kdump start

 


SLES11SP2：

 # chkconfig boot.kdump on 
 # service boot.kdump start

 


3.3.4  測試配置是否有效

能夠經過 kexec 加載內核鏡像，讓系統準備好去捕獲一個崩潰時產生的 vmcore。能夠經過 sysrq 強制系統崩潰。

# echo c > /proc/sysrq-trigger

 


這形成內核崩潰，如配置有效，系統將重啓進入 kdump 內核，當系統進程進入到啓動 kdump 服務的點時，vmcore 將會拷貝到你在 kdump 配置文件中設置的位置。RHEL 的缺省目錄是 : /var/crash；SLES 的缺省目錄是 : /var/log/dump。而後系統重啓進入到正常的內核。一旦回覆到正常的內核，就能夠在上述的目錄下發現 vmcore 文件，即內存轉儲文件。能夠使用以前安裝的 kernel-debuginfo 中的 crash 工具來進行分析（crash 的更多詳細用法將在本系列後面的文章中有介紹）。

 # crash /usr/lib/debug/lib/modules/2.6.17-1.2621.el5/vmlinux 
 /var/crash/2006-08-23-15:34/vmcore 
 crash> bt

 


3.4  載入「轉儲捕獲」內核

須要引導系統內核時，可以使用以下步驟和命令載入「轉儲捕獲」內核：

kexec -p <dump-capture-kernel> \ 
           --initrd=<initrd-for-dump-capture-kernel> --args-linux \ 
           --append="root=<root-dev> init 1 irqpoll"

 

裝載轉儲捕捉內核的注意事項：

  • 轉儲捕捉內核應當是一個 vmlinux 格式的映像（便是一個未壓縮的 ELF 映像文件），而不能是 bzImage 格式；

  • 默認狀況下，ELF 文件頭採用 ELF64 格式存儲以支持那些擁有超過 4GB 內存的系統。可是能夠指定「--elf32-core-headers」標誌以強制使用 ELF32 格式的 ELF 文件頭。這個標誌是有必要注意的，一個重要的緣由就是：當前版本的 GDB 不能在一個 32 位系統上打開一個使用 ELF64 格式的 vmcore 文件。ELF32 格式的文件頭不能使用在一個「沒有物理地址擴展」（non-PAE）的系統上（即：少於 4GB 內存的系統）;

  • 一個「irqpoll」的啓動參數能夠減低因爲在「轉儲捕獲內核」中使用了「共享中斷」技術而致使出現驅動初始化失敗這種狀況發生的機率 ;

  • 必須指定 <root-dev>，指定的格式是和要使用根設備的名字。具體能夠查看 mount 命令的輸出；「init 1」這個命令將啓動「轉儲捕捉內核」到一個沒有網絡支持的單用戶模式。若是你但願有網絡支持，那麼使用「init 3」。

 

3.5  後記

Kdump 是一個強大的、靈活的內核轉儲機制，可以在生產內核上下文中執行捕獲內核是很是有價值的。本文僅介紹在 RHEL6.2 和 SLES11 中如何配置 kdump。望拋磚引玉，對閱讀本文的讀者有益。


參考：

1  kallsyms的分析 
2   深刻探索 Kdump


九  KGDB

kgdb提供了一種使用 gdb調試 Linux 內核的機制。使用KGDB能夠象調試普通的應用程序那樣，在內核中進行設置斷點、檢查變量值、單步跟蹤程序運行等操做。使用KGDB調試時須要兩臺機器，一臺做爲開發機（Development Machine）,另外一臺做爲目標機（Target Machine），兩臺機器之間經過串口或者以太網口相連。串口鏈接線是一根RS-232接口的電纜，在其內部兩端的第2腳（TXD）與第3腳（RXD）交叉相連，第7腳（接地腳）直接相連。調試過程當中，被調試的內核運行在目標機上，gdb調試器運行在開發機上。 
目前，kgdb發佈支持i38六、x86_6四、32-bit PPC、SPARC等幾種體系結構的調試器。 

1  kgdb的調試原理

安裝kgdb調試環境須要爲Linux內核應用kgdb補丁，補丁實現的gdb遠程調試所須要的功能包括命令處理、陷阱處理及串口通信3個主要的部分。kgdb補丁的主要做用是在Linux內核中添加了一個調試Stub。調試Stub是Linux內核中的一小段代碼，提供了運行gdb的開發機和所調試內核之間的一個媒介。gdb和調試stub之間經過gdb串行協議進行通信。gdb串行協議是一種基於消息的ASCII碼協議，包含了各類調試命令。當設置斷點時，kgdb負責在設置斷點的指令前增長一條trap指令，當執行到斷點時控制權就轉移到調試stub中去。此時，調試stub的任務就是使用遠程串行通訊協議將當前環境傳送給gdb，而後從gdb處接受命令。gdb命令告訴stub下一步該作什麼，當stub收到繼續執行的命令時，將恢復程序的運行環境，把對CPU的控制權從新交還給內核  

2  Kgdb的安裝與設置

下面咱們將以Linux 2.6.7內核爲例詳細介紹kgdb調試環境的創建過程。 


2.1  軟硬件準備

如下軟硬件配置取自筆者進行試驗的系統配置狀況： 
kgdb補丁的版本遵循以下命名模式：Linux-A-kgdb-B，其中A表示Linux的內核版本號，B爲kgdb的版本號。以試驗使用的kgdb補丁爲例，linux內核的版本爲linux-2.6.7，補丁版本爲kgdb-2.2。 
物理鏈接好串口線後，使用如下命令來測試兩臺機器之間串口鏈接狀況，stty命令能夠對串口參數進行設置： 
在development機上執行： 

?
1
stty ispeed 115200 ospeed 115200 -F  /dev/ttyS0

 

在target機上執行： 

?
1
stty ispeed 115200 ospeed 115200 -F  /dev/ttyS0

 

在developement機上執行： 

?
1
echo  hello >  /dev/ttyS0

 

在target機上執行： 

?
1
cat  /dev/ttyS0

 

若是串口鏈接沒問題的話在將在target機的屏幕上顯示"hello"。 


2.2  安裝與配置

下面咱們須要應用kgdb補丁到Linux內核，設置內核選項並編譯內核。這方面的資料相對較少，筆者這裏給出詳細的介紹。下面的工做在開發機（developement）上進行，以上面介紹的試驗環境爲例，某些具體步驟在實際的環境中可能要作適當的改動： 


I、內核的配置與編譯

 

?
1
2
3
[root@lisl tmp] # tar -jxvf linux-2.6.7.tar.bz2
[root@lisl tmp] #tar -jxvf linux-2.6.7-kgdb-2.2.tar.tar
[root@lisl tmp] #cd inux-2.6.7

 

請參照目錄補丁包中文件README給出的說明，執行對應體系結構的補丁程序。因爲試驗在i386體系結構上完成，因此只須要安裝一下補丁：core-lite.patch、i386-lite.patch、8250.patch、eth.patch、core.patch、i386.patch。應用補丁文件時，請遵循kgdb軟件包內series文件所指定的順序，不然可能會帶來預想不到的問題。eth.patch文件是選擇以太網口做爲調試的鏈接端口時須要運用的補丁。 
應用補丁的命令以下所示： 

?
1
[root@lisl tmp] #patch -p1 <../linux-2.6.7-kgdb-2.2/core-lite.patch

 

若是內核正確，那麼應用補丁時應該不會出現任何問題（不會產生*.rej文件）。爲Linux內核添加了補丁以後，須要進行內核的配置。內核的配置能夠按照你的習慣選擇配置Linux內核的任意一種方式。 

?
1
[root@lisl tmp] #make menuconfig

 

在內核配置菜單的Kernel hacking選項中選擇kgdb調試項，例如： 

?
1
2
3
4
5
[*] KGDB: kernel debugging with remote  gdb
       Method  for  KGDB communication (KGDB: On generic serial port (8250))  --->  
  [*] KGDB: Thread analysis 
  [*] KGDB: Console messages through  gdb
[root@lisl tmp] #make

 

編譯內核以前請注意Linux目錄下Makefile中的優化選項，默認的Linux內核的編譯都以-O2的優化級別進行。在這個優化級別之下，編譯器要對內核中的某些代碼的執行順序進行改動，因此在調試時會出現程序運行與代碼順序不一致的狀況。能夠把Makefile中的-O2選項改成-O,但不可去掉-O，不然編譯會出問題。爲了使編譯後的內核帶有調試信息，注意在編譯內核的時候須要加上-g選項。 
不過，當選擇"Kernel debugging->Compile the kernel with debug info"選項後配置系統將自動打開調試選項。另外，選擇"kernel debugging with remote gdb"後，配置系統將自動打開"Compile the kernel with debug info"選項。 
內核編譯完成後，使用scp命令進行將相關文件拷貝到target機上(固然也能夠使用其它的網絡工具，如rcp)。 

?
1
2
[root@lisl tmp] #scp arch/i386/boot/bzImage root@192.168.6.13:/boot/vmlinuz-2.6.7-kgdb
[root@lisl tmp] #scp System.map root@192.168.6.13:/boot/System.map-2.6.7-kgdb

 

若是系統啓動使所須要的某些設備驅動沒有編譯進內核的狀況下，那麼還須要執行以下操做： 

?
1
2
[root@lisl tmp] #mkinitrd /boot/initrd-2.6.7-kgdb 2.6.7
[root@lisl tmp] #scp initrd-2.6.7-kgdb root@192.168.6.13:/boot/ initrd-2.6.7-kgdb

 


II、kgdb的啓動 
在將編譯出的內核拷貝的到target機器以後，須要配置系統引導程序，加入內核的啓動選項。如下是kgdb內核引導參數的說明： 
 
如表中所述，在kgdb 2.0版本以後內核的引導參數已經與之前的版本有所不一樣。使用grub引導程序時，直接將kgdb參數做爲內核vmlinuz的引導參數。下面給出引導器的配置示例。 

?
1
2
3
title 2.6.7 kgdb
root (hd0,0)
kernel  /boot/vmlinuz-2 .6.7-kgdb ro root= /dev/hda1  kgdbwait kgdb8250=1,115200

 

在使用lilo做爲引導程序時，須要把kgdb參放在由append修飾的語句中。下面給出使用lilo做爲引導器時的配置示例。

?
1
2
3
4
5
image= /boot/vmlinuz-2 .6.7-kgdb
label=kgdb
    read -only
    root= /dev/hda3
append= "gdb gdbttyS=1 gdbbaud=115200"

 

保存好以上配置後從新啓動計算機，選擇啓動帶調試信息的內核，內核將在短暫的運行後在建立init內核線程以前停下來，打印出如下信息，並等待開發機的鏈接。 
Waiting for connection from remote gdb... 
在開發機上執行： 

?
1
2
3
4
gdb
file  vmlinux
set  remotebaud 115200
target remote  /dev/ttyS0

 

其中vmlinux是指向源代碼目錄下編譯出來的Linux內核文件的連接，它是沒有通過壓縮的內核文件，gdb程序從該文件中獲得各類符號地址信息。 
這樣，就與目標機上的kgdb調試接口創建了聯繫。一旦創建聯接以後，對Linux內的調試工做與對普通的運用程序的調試就沒有什麼區別了。任什麼時候候均可以經過鍵入ctrl+c打斷目標機的執行，進行具體的調試工做。 
在kgdb 2.0以前的版本中，編譯內核後在arch/i386/kernel目錄下還會生成可執行文件gdbstart。將該文件拷貝到target機器的/boot目錄下，此時無需更改內核的啓動配置文件，直接使用命令： 

?
1
[root@lisl boot] #gdbstart -s 115200 -t /dev/ttyS0

 

能夠在KGDB內核引導啓動完成後創建開發機與目標機之間的調試聯繫。 

2.3  經過網絡接口進行調試 
kgdb也支持使用以太網接口做爲調試器的鏈接端口。在對Linux內核應用補丁包時，需應用eth.patch補丁文件。配置內核時在Kernel hacking中選擇kgdb調試項，配置kgdb調試端口爲以太網接口，例如： 

?
1
2
3
4
[*]KGDB: kernel debugging with remote  gdb
Method  for  KGDB communication (KGDB: On ethernet)  ---> 
( ) KGDB: On generic serial port (8250)
(X) KGDB: On ethernet

 

另外使用eth0網口做爲調試端口時，grub.list的配置以下： 

?
1
2
3
title 2.6.7 kgdb
root (hd0,0)
kernel  /boot/vmlinuz-2 .6.7-kgdb ro root= /dev/hda1  kgdbwait kgdboe=@192.168.5.13/,@192.168. 6.13/

 

其餘的過程與使用串口做爲鏈接端口時的設置過程相同。 
注意：儘管能夠使用以太網口做爲kgdb的調試端口，使用串口做爲鏈接端口更加簡單易行，kgdb項目組推薦使用串口做爲調試端口。 

2.4  模塊的調試方法 
內核可加載模塊的調試具備其特殊性。因爲內核模塊中各段的地址是在模塊加載進內核的時候才最終肯定的，因此develop機的gdb沒法獲得各類符號地址信息。因此，使用kgdb調試模塊所須要解決的一個問題是，須要經過某種方法得到可加載模塊的最終加載地址信息，並把這些信息加入到gdb環境中。 
I、在Linux 2.4內核中的內核模塊調試方法 
在Linux2.4.x內核中，能夠使用insmod -m命令輸出模塊的加載信息，例如： 

?
1
[root@lisl tmp] # insmod -m hello.ko >modaddr

 

查看模塊加載信息文件modaddr以下： 

?
1
2
3
4
5
6
7
.this           00000060  c88d8000  2**2
.text           00000035  c88d8060  2**2
.rodata         00000069  c88d80a0  2**5
……
.data           00000000  c88d833c  2**2
.bss            00000000  c88d833c  2**2
……

 

在這些信息中，咱們關心的只有4個段的地址:.text、.rodata、.data、.bss。在development機上將以上地址信息加入到gdb中,這樣就能夠進行模塊功能的測試了。 

?
1
( gdb ) Add-symbol- file  hello.o 0xc88d8060 -s .data 0xc88d80a0 -s .rodata 0xc88d80a0 -s .bss 0x c88d833c

 

這種方法也存在必定的不足，它不能調試模塊初始化的代碼，由於此時模塊初始化代碼已經執行過了。而若是不執行模塊的加載又沒法得到模塊插入地址，更不可能在模塊初始化以前設置斷點了。對於這種調試要求能夠採用如下替代方法。 
在target機上用上述方法獲得模塊加載的地址信息，而後再用rmmod卸載模塊。在development機上將獲得的模塊地址信息導入到gdb環境中，在內核代碼的調用初始化代碼以前設置斷點。這樣，在target機上再次插入模塊時，代碼將在執行模塊初始化以前停下來，這樣就能夠使用gdb命令調試模塊初始化代碼了。 
另一種調試模塊初始化函數的方法是：當插入內核模塊時，內核模塊機制將調用函數sys_init_module(kernel/modle.c)執行對內核模塊的初始化，該函數將調用所插入模塊的初始化函數。程序代碼片段以下： 

?
1
2
3
4
…… ……
if  (mod->init != NULL)
ret = mod->init();
…… ……

 

在該語句上設置斷點，也能在執行模塊初始化以前停下來。 


II、在Linux 2.6.x內核中的內核模塊調試方法

Linux 2.6以後的內核中，因爲module-init-tools工具的更改，insmod命令再也不支持-m參數，只有採起其餘的方法來獲取模塊加載到內核的地址。經過分析ELF文件格式，咱們知道程序中各段的意義以下： 
.text（代碼段）：用來存放可執行文件的操做指令，也就是說是它是可執行程序在內存種的鏡像。 
.data（數據段）：數據段用來存放可執行文件中已初始化全局變量，也就是存放程序靜態分配的變量和全局變量。 
.bss（BSS段）：BSS段包含了程序中未初始化全局變量，在內存中 bss段所有置零。 
.rodata（只讀段）：該段保存着只讀數據，在進程映象中構造不可寫的段。 
經過在模塊初始化函數中放置一下代碼，咱們能夠很容易地得到模塊加載到內存中的地址。 

?
1
2
3
4
5
6
7
8
9
10
11
……
int  bss_var;
static  int  hello_init( void )
{
printk(KERN_ALERT  "Text location .text(Code Segment):%p\n" ,hello_init);
static  int  data_var=0;
printk(KERN_ALERT  "Data Location .data(Data Segment):%p\n" ,&data_var);
printk(KERN_ALERT  "BSS Location: .bss(BSS Segment):%p\n" ,&bss_var);
……
}
Module_init(hello_init);

這裏，經過在模塊的初始化函數中添加一段簡單的程序，使模塊在加載時打印出在內核中的加載地址。.rodata段的地址能夠經過執行命令readelf -e hello.ko，取得.rodata在文件中的偏移量並加上段的align值得出。 
爲了使讀者可以更好地進行模塊的調試，kgdb項目還發布了一些腳本程序可以自動探測模塊的插入並自動更新gdb中模塊的符號信息。這些腳本程序的工做原理與前面解釋的工做過程類似，更多的信息請閱讀參考資料[4]。 

2.5  硬件斷點 
kgdb提供對硬件調試寄存器的支持。在kgdb中能夠設置三種硬件斷點：執行斷點（Execution Breakpoint）、寫斷點（Write Breakpoint）、訪問斷點（Access Breakpoint）但不支持I/O訪問的斷點。 目前，kgdb對硬件斷點的支持是經過宏來實現的，最多能夠設置4個硬件斷點，這些宏的用法以下： 
 
在有些狀況下，硬件斷點的使用對於內核的調試是很是方便的。 

3  在VMware中搭建調試環境

kgdb調試環境須要使用兩臺微機分別充當development機和target機，使用VMware後咱們只使用一臺計算機就能夠順利完成kgdb調試環境的搭建。以windows下的環境爲例，建立兩臺虛擬機，一臺做爲開發機，一臺做爲目標機。 

3.1  虛擬機之間的串口鏈接 
虛擬機中的串口鏈接能夠採用兩種方法。一種是指定虛擬機的串口鏈接到實際的COM上，例如開發機鏈接到COM1，目標機鏈接到COM2，而後把兩個串口經過串口線相鏈接。另外一種更爲簡便的方法是：在較高一些版本的VMware中都支持把串口映射到命名管道，把兩個虛擬機的串口映射到同一個命名管道。例如，在兩個虛擬機中都選定同一個命名管道 \\.\pipe\com_1,指定target機的COM口爲server端，並選擇"The other end is a virtual machine"屬性；指定development機的COM口端爲client端，一樣指定COM口的"The other end is a virtual machine"屬性。對於IO mode屬性，在target上選中"Yield CPU on poll"複選擇框，development機不選。這樣，能夠無需附加任何硬件，利用虛擬機就能夠搭建kgdb調試環境。 即下降了使用kgdb進行調試的硬件要求，也簡化了創建調試環境的過程。 
 


3.2  VMware的使用技巧

VMware虛擬機是比較佔用資源的，尤爲是象上面那樣在Windows中使用兩臺虛擬機。所以，最好爲系統配備512M以上的內存，每臺虛擬機至少分配128M的內存。這樣的硬件要求，對目前主流配置的PC而言並非太高的要求。出於系統性能的考慮，在VMware中儘可能使用字符界面進行調試工做。同時，Linux系統默認狀況下開啓了sshd服務，建議使用SecureCRT登錄到Linux進行操做，這樣能夠有較好的用戶使用界面。 

3.3  在Linux下的虛擬機中使用kgdb 
對於在Linux下面使用VMware虛擬機的狀況，筆者沒有作過實際的探索。從原理上而言，只須要在Linux下只要建立一臺虛擬機做爲target機，開發機的工做能夠在實際的Linux環境中進行，搭建調試環境的過程與上面所述的過程相似。因爲只須要建立一臺虛擬機，因此使用Linux下的虛擬機搭建kgdb調試環境對系統性能的要求較低。（vmware已經推出了Linux下的版本）還能夠在development機上配合使用一些其餘的調試工具，例如功能更強大的cgdb、圖形界面的DDD調試器等，以方便內核的調試工做。 
 


4  kgdb的一些特色和不足

使用kgdb做爲內核調試環境最大的不足在於對kgdb硬件環境的要求較高，必須使用兩臺計算機分別做爲target和development機。儘管使用虛擬機的方法能夠只用一臺PC即能搭建調試環境，可是對系統其餘方面的性能也提出了必定的要求，同時也增長了搭建調試環境時複雜程度。另外，kgdb內核的編譯、配置也比較複雜，須要必定的技巧，筆者當時作的時候也是費了不少周折。當調試過程結束後時，還須要從新制做所要發佈的內核。使用kgdb並不能進行全程調試，也就是說kgdb並不能用於調試系統一開始的初始化引導過程。 
不過，kgdb是一個不錯的內核調試工具，使用它能夠進行對內核的全面調試，甚至能夠調試內核的中斷處理程序。若是在一些圖形化的開發工具的幫助下，對內核的調試將更方便。 

參考： 
透過虛擬化技術體驗kgdb 
Linux 系統內核的調試 
Debugging The Linux Kernel Using Gdb 


十  使用SkyEye構建Linux內核調試環境

SkyEye是一個開源軟件項目（OPenSource Software）,SkyEye項目的目標是在通用的Linux和Windows平臺上模擬常見的嵌入式計算機系統。SkyEye實現了一個指令級的硬件模擬平臺，能夠模擬多種嵌入式開發板，支持多種CPU指令集。SkyEye 的核心是 GNU 的 gdb 項目，它把gdb和 ARM Simulator很好地結合在了一塊兒。加入ARMulator 的功能以後，它就能夠來仿真嵌入式開發板，在它上面不只能夠調試硬件驅動，還能夠調試操做系統。Skyeye項目目前已經在嵌入式系統開發領域獲得了很大的推廣。 

1  SkyEye的安裝和μcLinux內核編譯

1.1  SkyEye的安裝 
SkyEye的安裝不是本文要介紹的重點，目前已經有大量的資料對此進行了介紹。有關SkyEye的安裝與使用的內容請查閱參考資料[11]。因爲skyeye面目主要用於嵌入式系統領域，因此在skyeye上常用的是μcLinux系統，固然使用Linux做爲skyeye上運行的系統也是能夠的。因爲介紹μcLinux 2.6在skyeye上編譯的相關資料並很少，因此下面進行詳細介紹。 

1.2  μcLinux 2.6.x的編譯 
要在SkyEye中調試操做系統內核，首先必須使被調試內核能在SkyEye所模擬的開發板上正確運行。所以，正確編譯待調試操做系統內核並配置SkyEye是進行內核調試的第一步。下面咱們以SkyEye模擬基於Atmel AT91X40的開發板，並運行μcLinux 2.6爲例介紹SkyEye的具體調試方法。 

I、安裝交叉編譯環境 
先安裝交叉編譯器。儘管在一些資料中說明使用工具鏈arm-elf-tools-20040427.sh ,可是因爲arm-elf-xxx與arm-linux-xxx對宏及連接處理的不一樣，經驗證實使用arm-elf-xxx工具鏈在連接vmlinux的最後階段將會出錯。因此這裏咱們使用的交叉編譯工具鏈是：arm-uclinux-tools-base-gcc3.4.0-20040713.sh，關於該交叉編譯工具鏈的下載地址請參見[6]。注意如下步驟最好用root用戶來執行。 

?
1
2
[root@lisl tmp] #chmod +x  arm-uclinux-tools-base-gcc3.4.0-20040713.sh
[root@lisl tmp] #./arm-uclinux-tools-base-gcc3.4.0-20040713.sh

 

安裝交叉編譯工具鏈以後，請確保工具鏈安裝路徑存在於系統PATH變量中。 

II、製做μcLinux內核 
獲得μcLinux發佈包的一個最容易的方法是直接訪問uClinux.org站點[7]。該站點發布的內核版本可能不是最新的，但你能找到一個最新的μcLinux補丁以及找一個對應的Linux內核版原本製做一個最新的μcLinux內核。這裏，將使用這種方法來製做最新的μcLinux內核。目前（筆者記錄編寫此文章時），所能獲得的發佈包的最新版本是uClinux-dist.20041215.tar.gz。 
下載uClinux-dist.20041215.tar.gz，文件的下載地址請參見[7]。 
下載linux-2.6.9-hsc0.patch.gz，文件的下載地址請參見[8]。 
下載linux-2.6.9.tar.bz2，文件的下載地址請參見[9]。 
如今咱們獲得了整個的linux-2.6.9源代碼，以及所需的內核補丁。請準備一個有2GB空間的目錄裏來完成如下製做μcLinux內核的過程。 

?
1
2
3
[root@lisl tmp] # tar -jxvf uClinux-dist-20041215.tar.bz2
[root@lisl uClinux-dist] # tar -jxvf  linux-2.6.9.tar.bz2
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程