Linux中國

調試器工作原理（一）：基礎篇

361 views0
By
Share

這是調試器工作原理系列文章的第一篇，我不確定這個系列會有多少篇文章，會涉及多少話題，但我仍會從這篇基礎開始。

這一篇會講什麼

我將為大家展示 Linux 中調試器的主要構成模塊 - ptrace 系統調用。這篇文章所有代碼都是基於 32 位 Ubuntu 操作系統。值得注意的是，儘管這些代碼是平台相關的，將它們移植到其它平台應該並不困難。

緣由

為了理解我們要做什麼，讓我們先考慮下調試器為了完成調試都需要什麼資源。調試器可以開始一個進程並調試這個進程，又或者將自己同某個已經存在的進程關聯起來。調試器能夠單步執行代碼，設定斷點並且將程序執行到斷點，檢查變數的值並追蹤堆棧。許多調試器有著更高級的特性，例如在調試器的地址空間內執行表達式或者調用函數，甚至可以在進程執行過程中改變代碼並觀察效果。

儘管現代的調試器都十分的複雜（我沒有檢查，但我確信 gdb 的代碼行數至少有六位數），但它們的工作的原理卻是十分的簡單。調試器的基礎是操作系統與編譯器 / 鏈接器提供的一些基礎服務，其餘的部分只是簡單的編程而已。

Linux 的調試 - ptrace

Linux 調試器中的瑞士軍刀便是 ptrace 系統調用（使用 man 2 ptrace 命令可以了解更多）。這是一種複雜卻強大的工具，可以允許一個進程式控制制另外一個進程並從 內部替換 Peek and poke 被控制進程的內核鏡像的值（Peek and poke 在系統編程中是很知名的叫法，指的是直接讀寫內存內容）。

接下來會深入分析。

執行進程的代碼

我將編寫一個示例，實現一個在「跟蹤」模式下運行的進程。在這個模式下，我們將單步執行進程的代碼，就像機器碼（彙編代碼）被 CPU 執行時一樣。我將分段展示、講解示例代碼，在文章的末尾也有完整 c 文件的下載鏈接，你可以編譯、執行或者隨心所欲的更改。

更進一步的計劃是實現一段代碼，這段代碼可以創建可執行用戶自定義命令的子進程，同時父進程可以跟蹤子進程。首先是主函數：

int main(int argc, char** argv)
{
    pid_t child_pid;

    if (argc < 2) {
        fprintf(stderr, "Expected a program name as argumentn");
        return -1;
    }

    child_pid = fork();
    if (child_pid == 0)
        run_target(argv[1]);
    else if (child_pid > 0)
        run_debugger(child_pid);
    else {
        perror("fork");
        return -1;
    }

    return 0;
}

看起來相當的簡單：我們用 fork 創建了一個新的子進程（這篇文章假定讀者有一定的 Unix/Linux 編程經驗。我假定你知道或至少了解 fork、exec 族函數與 Unix 信號）。if 語句的分支執行子進程（這裡稱之為 「target」），else if 的分支執行父進程（這裡稱之為 「debugger」）。

下面是 target 進程的代碼：

void run_target(const char* programname)
{
    procmsg("target started. will run &apos;%s&apos;n", programname);

    /* Allow tracing of this process */
    if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
        perror("ptrace");
        return;
    }

    /* Replace this process&apos;s image with the given program */
    execl(programname, programname, 0);
}

這段代碼中最值得注意的是 ptrace 調用。在 sys/ptrace.h 中，ptrace 是如下定義的：

long ptrace(enum __ptrace_request request, pid_t pid,
                 void *addr, void *data);

第一個參數是 _request_，這是許多預定義的 PTRACE_* 常量中的一個。第二個參數為請求分配進程 ID。第三個與第四個參數是地址與數據指針，用於操作內存。上面代碼段中的 ptrace 調用發起了 PTRACE_TRACEME 請求，這意味著該子進程請求系統內核讓其父進程跟蹤自己。幫助頁面上對於 request 的描述很清楚：

意味著該進程被其父進程跟蹤。任何傳遞給該進程的信號（除了 SIGKILL）都將通過 wait() 方法阻塞該進程並通知其父進程。此外，該進程的之後所有調用 exec() 動作都將導致 SIGTRAP 信號發送到此進程上，使得父進程在新的程序執行前得到取得控制權的機會。如果一個進程並不需要它的的父進程跟蹤它，那麼這個進程不應該發送這個請求。（pid、addr 與 data 暫且不提）

我高亮了這個例子中我們需要注意的部分。在 ptrace 調用後，run_target 接下來要做的就是通過 execl 傳參並調用。如同高亮部分所說明，這將導致系統內核在 execl 創建進程前暫時停止，並向父進程發送信號。

是時候看看父進程做什麼了。

void run_debugger(pid_t child_pid)
{
    int wait_status;
    unsigned icounter = 0;
    procmsg("debugger startedn");

    /* Wait for child to stop on its first instruction */
    wait(&wait_status);

    while (WIFSTOPPED(wait_status)) {
        icounter++;
        /* Make the child execute another instruction */
        if (ptrace(PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) {
            perror("ptrace");
            return;
        }

        /* Wait for child to stop on its next instruction */
        wait(&wait_status);
    }

    procmsg("the child executed %u instructionsn", icounter);
}

如前文所述，一旦子進程調用了 exec，子進程會停止並被發送 SIGTRAP 信號。父進程會等待該過程的發生並在第一個 wait() 處等待。一旦上述事件發生了，wait() 便會返回，由於子進程停止了父進程便會收到信號（如果子進程由於信號的發送停止了，WIFSTOPPED 就會返回 true）。

父進程接下來的動作就是整篇文章最需要關注的部分了。父進程會將 PTRACE_SINGLESTEP 與子進程 ID 作為參數調用 ptrace 方法。這就會告訴操作系統，「請恢復子進程，但在它執行下一條指令前阻塞」。周而復始地，父進程等待子進程阻塞，循環繼續。當 wait() 中傳出的信號不再是子進程的停止信號時，循環終止。在跟蹤器（父進程）運行期間，這將會是被跟蹤進程（子進程）傳遞給跟蹤器的終止信號（如果子進程終止 WIFEXITED 將返回 true）。

icounter 存儲了子進程執行指令的次數。這麼看來我們小小的例子也完成了些有用的事情 - 在命令行中指定程序，它將執行該程序並記錄它從開始到結束所需要的 cpu 指令數量。接下來就讓我們這麼做吧。

測試

我編譯了下面這個簡單的程序並利用跟蹤器運行它：

#include <stdio.h>

int main()
{
    printf("Hello, world!n");
    return 0;
}

令我驚訝的是，跟蹤器花了相當長的時間，並報告整個執行過程共有超過 100,000 條指令執行。僅僅是一條輸出語句？什麼造成了這種情況？答案很有趣（至少你同我一樣痴迷與機器/彙編語言）。Linux 的 gcc 默認會動態的將程序與 c 的運行時庫動態地鏈接。這就意味著任何程序運行前的第一件事是需要動態庫載入器去查找程序運行所需要的共享庫。這些代碼的數量很大 - 別忘了我們的跟蹤器要跟蹤每一條指令，不僅僅是主函數的，而是「整個進程中的指令」。

所以當我將測試程序使用靜態編譯時（通過比較，可執行文件會多出 500 KB 左右的大小，這部分是 C 運行時庫的靜態鏈接），跟蹤器提示只有大概 7000 條指令被執行。這個數目仍然不小，但是考慮到在主函數執行前 libc 的初始化以及主函數執行後的清除代碼，這個數目已經是相當不錯了。此外，printf 也是一個複雜的函數。

仍然不滿意的話，我需要的是「可以測試」的東西 - 例如可以完整記錄每一個指令運行的程序執行過程。這當然可以通過彙編代碼完成。所以我找到了這個版本的 「Hello, world!」 並編譯了它。

section    .text
    ; The _start symbol must be declared for the linker (ld)
    global _start

_start:

    ; Prepare arguments for the sys_write system call:
    ;   - eax: system call number (sys_write)
    ;   - ebx: file descriptor (stdout)
    ;   - ecx: pointer to string
    ;   - edx: string length
    mov    edx, len
    mov    ecx, msg
    mov    ebx, 1
    mov    eax, 4

    ; Execute the sys_write system call
    int    0x80

    ; Execute sys_exit
    mov    eax, 1
    int    0x80

section   .data
msg db    &apos;Hello, world!&apos;, 0xa
len equ    $ - msg

當然，現在跟蹤器提示 7 條指令被執行了，這樣一來很容易區分它們。

深入指令流

上面那個彙編語言編寫的程序使得我可以向你介紹 ptrace 的另外一個強大的用途 - 詳細顯示被跟蹤進程的狀態。下面是 run_debugger 函數的另一個版本：

void run_debugger(pid_t child_pid)
{
    int wait_status;
    unsigned icounter = 0;
    procmsg("debugger startedn");

    /* Wait for child to stop on its first instruction */
    wait(&wait_status);

    while (WIFSTOPPED(wait_status)) {
        icounter++;
        struct user_regs_struct regs;
        ptrace(PTRACE_GETREGS, child_pid, 0, &regs);
        unsigned instr = ptrace(PTRACE_PEEKTEXT, child_pid, regs.eip, 0);

        procmsg("icounter = %u.  EIP = 0x%08x.  instr = 0x%08xn",
                    icounter, regs.eip, instr);

        /* Make the child execute another instruction */
        if (ptrace(PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) {
            perror("ptrace");
            return;
        }

        /* Wait for child to stop on its next instruction */
        wait(&wait_status);
    }

    procmsg("the child executed %u instructionsn", icounter);
}

不同僅僅存在於 while 循環的開始幾行。這個版本里增加了兩個新的 ptrace 調用。第一條將進程的寄存器值讀取進了一個結構體中。 sys/user.h 定義有 user_regs_struct。如果你查看頭文件，頭部的注釋這麼寫到：

/* 這個文件只為了 GDB 而創建
   不用詳細的閱讀.如果你不知道你在幹嘛，
   不要在除了 GDB 以外的任何地方使用此文件  */

不知道你做何感想，但這讓我覺得我們找對地方了。回到例子中，一旦我們在 regs 變數中取得了寄存器的值，我們就可以通過將 PTRACE_PEEKTEXT 作為參數、 regs.eip（x86 上的擴展指令指針）作為地址，調用 ptrace ，讀取當前進程的當前指令（警告：如同我上面所說，文章很大程度上是平台相關的。我簡化了一些設定 - 例如，x86 指令集不需要調整到 4 位元組，我的32位 Ubuntu unsigned int 是 4 位元組。事實上，許多平台都不需要。從內存中讀取指令需要預先安裝完整的反彙編器。我們這裡沒有，但實際的調試器是有的）。下面是新跟蹤器所展示出的調試效果：

$ simple_tracer traced_helloworld
[5700] debugger started
[5701] target started. will run &apos;traced_helloworld&apos;
[5700] icounter = 1.  EIP = 0x08048080.  instr = 0x00000eba
[5700] icounter = 2.  EIP = 0x08048085.  instr = 0x0490a0b9
[5700] icounter = 3.  EIP = 0x0804808a.  instr = 0x000001bb
[5700] icounter = 4.  EIP = 0x0804808f.  instr = 0x000004b8
[5700] icounter = 5.  EIP = 0x08048094.  instr = 0x01b880cd
Hello, world!
[5700] icounter = 6.  EIP = 0x08048096.  instr = 0x000001b8
[5700] icounter = 7.  EIP = 0x0804809b.  instr = 0x000080cd
[5700] the child executed 7 instructions

現在，除了 icounter，我們也可以觀察到指令指針與它每一步所指向的指令。怎麼來判斷這個結果對不對呢？使用 objdump -d 處理可執行文件：

$ objdump -d traced_helloworld

traced_helloworld:     file format elf32-i386

Disassembly of section .text:

08048080 <.text>:
 8048080:     ba 0e 00 00 00          mov    $0xe,%edx
 8048085:     b9 a0 90 04 08          mov    $0x80490a0,%ecx
 804808a:     bb 01 00 00 00          mov    $0x1,%ebx
 804808f:     b8 04 00 00 00          mov    $0x4,%eax
 8048094:     cd 80                   int    $0x80
 8048096:     b8 01 00 00 00          mov    $0x1,%eax
 804809b:     cd 80                   int    $0x80

這個結果和我們跟蹤器的結果就很容易比較了。

　將跟蹤器關聯到正在運行的進程

如你所知，調試器也能關聯到已經運行的進程。現在你應該不會驚訝，ptrace 通過以 PTRACE_ATTACH 為參數調用也可以完成這個過程。這裡我不會展示示例代碼，通過上文的示例代碼應該很容易實現這個過程。出於學習目的，這裡使用的方法更簡便（因為我們在子進程剛開始就可以讓它停止）。

代碼

上文中的簡單的跟蹤器（更高級的，可以列印指令的版本）的完整c源代碼可以在這裡找到。它是通過 4.4 版本的 gcc 以 -Wall -pedantic --std=c99 編譯的。

結論與計劃

誠然，這篇文章並沒有涉及很多內容 - 我們距離親手完成一個實際的調試器還有很長的路要走。但我希望這篇文章至少可以使得調試這件事少一些神秘感。ptrace 是功能多樣的系統調用，我們目前只展示了其中的一小部分。

單步調試代碼很有用，但也只是在一定程度上有用。上面我通過 C 的 「Hello World!」 做了示例。為了執行主函數，可能需要上萬行代碼來初始化 C 的運行環境。這並不是很方便。最理想的是在 main 函數入口處放置斷點並從斷點處開始分步執行。為此，在這個系列的下一篇，我打算展示怎麼實現斷點。

參考

撰寫此文時參考了如下文章：

via: http://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1

作者：Eli Bendersky 譯者：YYforymj 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive

對這篇文章感覺如何？

太棒了
0
不錯
0
愛死了
0
不太好
0
感覺很糟
0
雨落清風。心向陽
    Previous
    Next

    You may also like

    Leave a reply

    您的電子郵箱地址不會被公開。 必填項已用 * 標註

    此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據。

    More in:Linux中國