閱讀(42.8k) 書簽贊(0) 我要糾錯

代碼測試、調(diào)試與優(yōu)化

2018-02-24 15:41 更新

代碼測試、調(diào)試與優(yōu)化

前言
代碼測試

前言

代碼寫完以后往往要做測試（或驗證）、調(diào)試，可能還要優(yōu)化。

關(guān)于測試（或驗證）

通常對應(yīng)著兩個英文單詞 Verification 和 Validation，在資料 [1] 中有關(guān)于這個的定義和一些深入的討論，在資料 [2] 中，很多人給出了自己的看法。但是正如資料 [2] 提到的：

The differences between verification and validation are unimportant except to the theorist; practitioners use the term V&V to refer to all of the activities that are aimed at making sure the software will function as required.

所以，無論測試（或驗證）目的都是為了讓軟件的功能能夠達(dá)到需求。測試和驗證通常會通過一些形式化（貌似可以簡單地認(rèn)為有數(shù)學(xué)根據(jù)的）或者非形式化的方法去驗證程序的功能是否達(dá)到要求。

關(guān)于調(diào)試

而調(diào)試對應(yīng)英文 debug，debug 叫“驅(qū)除害蟲”，也許一個軟件的功能達(dá)到了要求，但是可能會在測試或者是正常運(yùn)行時出現(xiàn)異常，因此需要處理它們。

關(guān)于優(yōu)化

debug 是為了保證程序的正確性，之后就需要考慮程序的執(zhí)行效率，對于存儲資源受限的嵌入式系統(tǒng)，程序的大小也可能是優(yōu)化的對象。

很多理論性的東西實在沒有研究過，暫且不說吧。這里只是想把一些需要動手實踐的東西先且記錄和總結(jié)一下，另外很多工具在這里都有提到和羅列，包括 Linux 內(nèi)核調(diào)試相關(guān)的方法和工具。關(guān)于更詳細(xì)更深入的內(nèi)容還是建議直接看后面的參考資料為妙。

下面的所有演示在如下環(huán)境下進(jìn)行：

$ uname -a
Linux falcon 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
$ echo $SHELL
/bin/bash
$ /bin/bash --version | grep bash
GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu)
$ gcc --version | grep gcc
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
$ cat /proc/cpuinfo | grep "model name"
model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz

代碼測試

代碼測試有很多方面，例如運(yùn)行時間、函數(shù)調(diào)用關(guān)系圖、代碼覆蓋度、性能分析（Profiling）、內(nèi)存訪問越界（Segmentation Fault）、緩沖區(qū)溢出（Stack Smashing 合法地進(jìn)行非法的內(nèi)存訪問？所以很危險）、內(nèi)存泄露（Memory Leak）等。

測試程序的運(yùn)行時間 time

Shell 提供了內(nèi)置命令 time 用于測試程序的執(zhí)行時間，默認(rèn)顯示結(jié)果包括三部分：實際花費時間（real time）、用戶空間花費時間（user time）和內(nèi)核空間花費時間（kernel time）。

$ time pstree 2>&1 >/dev/null

real    0m0.024s
user    0m0.008s
sys     0m0.004s

time 命令給出了程序本身的運(yùn)行時間。這個測試原理非常簡單，就是在程序運(yùn)行（通過 system 函數(shù)執(zhí)行）前后記錄了系統(tǒng)時間（用 times 函數(shù)），然后進(jìn)行求差就可以。如果程序運(yùn)行時間很短，運(yùn)行一次看不到效果，可以考慮采用測試紙片厚度的方法進(jìn)行測試，類似把很多紙張疊到一起來測試紙張厚度一樣，我們可以讓程序運(yùn)行很多次。

如果程序運(yùn)行時間太長，執(zhí)行效率很低，那么得考慮程序內(nèi)部各個部分的執(zhí)行情況，從而對代碼進(jìn)行可能的優(yōu)化。具體可能會考慮到這兩點：

對于 C 語言程序而言，一個比較宏觀的層次性的輪廓（profile）是函數(shù)調(diào)用圖、函數(shù)內(nèi)部的條件分支構(gòu)成的語句塊，然后就是具體的語句。把握好這樣一個輪廓后，就可以有針對性地去關(guān)注程序的各個部分，包括哪些函數(shù)、哪些分支、哪些語句最值得關(guān)注（執(zhí)行次數(shù)越多越值得優(yōu)化，術(shù)語叫 hotspots）。

對于 Linux 下的程序而言，程序運(yùn)行時涉及到的代碼會涵蓋兩個空間，即用戶空間和內(nèi)核空間。由于這兩個空間涉及到地址空間的隔離，在測試或調(diào)試時，可能涉及到兩個空間的工具。前者絕大多數(shù)是基于 Gcc 的特定參數(shù)和系統(tǒng)的 ptrace 調(diào)用，而后者往往實現(xiàn)為內(nèi)核的補(bǔ)丁，它們在原理上可能類似，但實際操作時后者顯然會更麻煩，不過如果你不去 hack 內(nèi)核，那么往往無須關(guān)心后者。

函數(shù)調(diào)用關(guān)系圖 calltree

calltree 可以非常簡單方便地反應(yīng)一個項目的函數(shù)調(diào)用關(guān)系圖，雖然諸如 gprof 這樣的工具也能做到，不過如果僅僅要得到函數(shù)調(diào)用圖，calltree 應(yīng)該是更好的選擇。如果要產(chǎn)生圖形化的輸出可以使用它的 -dot 參數(shù)。從這里可以下載到它。

這里是一份基本用法演示結(jié)果：

$ calltree -b -np -m *.c
main:
|   close
|   commitchanges
|   |   err
|   |   |   fprintf
|   |   ferr
|   |   ftruncate
|   |   lseek
|   |   write
|   ferr
|   getmemorysize
|   modifyheaders
|   open
|   printf
|   readelfheader
|   |   err
|   |   |   fprintf
|   |   ferr
|   |   read
|   readphdrtable
|   |   err
|   |   |   fprintf
|   |   ferr
|   |   malloc
|   |   read
|   truncatezeros
|   |   err
|   |   |   fprintf
|   |   ferr
|   |   lseek
|   |   read$

這樣一份結(jié)果對于“反向工程”應(yīng)該會很有幫助，它能夠呈現(xiàn)一個程序的大體結(jié)構(gòu)，對于閱讀和分析源代碼來說是一個非常好的選擇。雖然 cscope 和 ctags 也能夠提供一個函數(shù)調(diào)用的“即時”（在編輯 Vim 的過程中進(jìn)行調(diào)用）視圖（view），但是 calltree 卻給了我們一個宏觀的視圖。

不過這樣一個視圖只涉及到用戶空間的函數(shù)，如果想進(jìn)一步給出內(nèi)核空間的宏觀視圖，那么 strace，KFT 或者 Ftrace 就可以發(fā)揮它們的作用。另外，該視圖也沒有給出庫中的函數(shù)，如果要跟蹤呢？需要 ltrace 工具。

另外發(fā)現(xiàn) calltree 僅僅給出了一個程序的函數(shù)調(diào)用視圖，而沒有告訴我們各個函數(shù)的執(zhí)行次數(shù)等情況。如果要關(guān)注這些呢？我們有 gprof。

性能測試工具 gprof & kprof

參考資料[3]詳細(xì)介紹了這個工具的用法，這里僅挑選其中一個例子來演示。gprof 是一個命令行的工具，而 KDE 桌面環(huán)境下的 kprof 則給出了圖形化的輸出，這里僅演示前者。

首先來看一段代碼（來自資料[3]），算 Fibonacci 數(shù)列的，

#include <stdio.h>

int fibonacci(int n);

int main (int argc, char **argv)
{
    int fib;
    int n;

    for (n = 0; n <= 42; n++) {
        fib = fibonacci(n);
        printf("fibonnaci(%d) = %d\n", n, fib);
    }

    return 0;
}

int fibonacci(int n)
{
    int fib;

    if (n <= 0) {
        fib = 0;
    } else if (n == 1) {
        fib = 1;
    } else {
        fib = fibonacci(n -1) + fibonacci(n - 2);
    }

    return fib;
}

通過 calltree 看看這段代碼的視圖，

$ calltree -b -np -m *.c
main:
|   fibonacci
|   |   fibonacci ....
|   printf

可以看出程序主要涉及到一個 fibonacci 函數(shù)，這個函數(shù)遞歸調(diào)用自己。為了能夠使用 gprof，需要編譯時加上 -pg 選項，讓 Gcc 加入相應(yīng)的調(diào)試信息以便 gprof 能夠產(chǎn)生函數(shù)執(zhí)行情況的報告。

$ gcc -pg -o fib fib.c
$ ls
fib  fib.c

運(yùn)行程序并查看執(zhí)行時間，

$ time ./fib
fibonnaci(0) = 0
fibonnaci(1) = 1
fibonnaci(2) = 1
fibonnaci(3) = 2
...
fibonnaci(41) = 165580141
fibonnaci(42) = 267914296

real    1m25.746s
user    1m9.952s
sys     0m0.072s
$ ls
fib  fib.c  gmon.out

上面僅僅選取了部分執(zhí)行結(jié)果，程序運(yùn)行了 1 分多鐘，代碼運(yùn)行以后產(chǎn)生了一個 gmon.out 文件，這個文件可以用于 gprof 產(chǎn)生一個相關(guān)的性能報告。

$ gprof  -b ./fib gmon.out 
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 96.04     14.31    14.31       43   332.80   332.80  fibonacci
  4.59     14.99     0.68                             main

                        Call graph

granularity: each sample hit covers 2 byte(s) for 0.07% of 14.99 seconds

index % time    self  children    called     name
                                                 <spontaneous>
[1]    100.0    0.68   14.31                 main [1]
               14.31    0.00      43/43          fibonacci [2]
-----------------------------------------------
                             2269806252             fibonacci [2]
               14.31    0.00      43/43          main [1]
[2]     95.4   14.31    0.00      43+2269806252 fibonacci [2]
                             2269806252             fibonacci [2]
-----------------------------------------------

Index by function name

   [2] fibonacci               [1] main

從這份結(jié)果中可觀察到程序中每個函數(shù)的執(zhí)行次數(shù)等情況，從而找出值得修改的函數(shù)。在對某些部分修改之后，可以再次比較程序運(yùn)行時間，查看優(yōu)化結(jié)果。另外，這份結(jié)果還包含一個特別有用的東西，那就是程序的動態(tài)函數(shù)調(diào)用情況，即程序運(yùn)行過程中實際執(zhí)行過的函數(shù)，這和 calltree 產(chǎn)生的靜態(tài)調(diào)用樹有所不同，它能夠反應(yīng)程序在該次執(zhí)行過程中的函數(shù)調(diào)用情況。而如果想反應(yīng)程序運(yùn)行的某一時刻調(diào)用過的函數(shù)，可以考慮采用 gdb 的 backtrace 命令。

類似測試紙片厚度的方法，gprof 也提供了一個統(tǒng)計選項，用于對程序的多次運(yùn)行結(jié)果進(jìn)行統(tǒng)計。另外，gprof 有一個 KDE 下圖形化接口 kprof，這兩部分請參考資料[3]。

對于非 KDE 環(huán)境，可以使用 Gprof2Dot 把 gprof 輸出轉(zhuǎn)換成圖形化結(jié)果。

關(guān)于 dot 格式的輸出，也可以可以考慮通過 dot 命令把結(jié)果轉(zhuǎn)成 jpg 等格式，例如：

$ dot -Tjpg test.dot -o test.jp

gprof 雖然給出了函數(shù)級別的執(zhí)行情況，但是如果想關(guān)心具體哪些條件分支被執(zhí)行到，哪些語句沒有被執(zhí)行，該怎么辦？

代碼覆蓋率測試 gcov & ggcov

如果要使用 gcov，在編譯時需要加上這兩個選項 -fprofile-arcs -ftest-coverage，這里直接用之前的 fib.c 做演示。

$ ls
fib.c
$ gcc -fprofile-arcs -ftest-coverage -o fib fib.c
$ ls
fib  fib.c  fib.gcno

運(yùn)行程序，并通過 gcov 分析代碼的覆蓋度：

$ ./fib
$ gcov fib.c
File 'fib.c'
Lines executed:100.00% of 12
fib.c:creating 'fib.c.gcov'

12 行代碼 100% 被執(zhí)行到，再查看分支情況，

$ gcov -b fib.c
File 'fib.c'
Lines executed:100.00% of 12
Branches executed:100.00% of 6
Taken at least once:100.00% of 6
Calls executed:100.00% of 4
fib.c:creating 'fib.c.gcov'

發(fā)現(xiàn)所有函數(shù)，條件分支和語句都被執(zhí)行到，說明代碼的覆蓋率很高，不過資料[3]gprof 的演示顯示代碼的覆蓋率高并不一定說明代碼的性能就好，因為那些被覆蓋到的代碼可能能夠被優(yōu)化成性能更高的代碼。那到底哪些代碼值得被優(yōu)化呢？執(zhí)行次數(shù)最多的，另外，有些分支雖然都覆蓋到了，但是這個分支的位置可能并不是理想的，如果一個分支的內(nèi)容被執(zhí)行的次數(shù)很多，那么把它作為最后一個分支的話就會浪費很多不必要的比較時間。因此，通過覆蓋率測試，可以嘗試著剔除那些從未執(zhí)行過的代碼或者把那些執(zhí)行次數(shù)較多的分支移動到較早的條件分支里頭。通過性能測試，可以找出那些值得優(yōu)化的函數(shù)、分支或者是語句。

如果使用 -fprofile-arcs -ftest-coverage 參數(shù)編譯完代碼，可以接著用 -fbranch-probabilities 參數(shù)對代碼進(jìn)行編譯，這樣，編譯器就可以對根據(jù)代碼的分支測試情況進(jìn)行優(yōu)化。

$ wc -c fib
16333 fib
$ ls fib.gcda  #確保fib.gcda已經(jīng)生成，這個是運(yùn)行fib后的結(jié)果
fib.gcda
$ gcc -fbranch-probabilities -o fib fib.c #再次運(yùn)行
$ wc -c fib
6604 fib
$ time ./fib
...
real    0m21.686s
user    0m18.477s
sys     0m0.008s

可見代碼量減少了，而且執(zhí)行效率會有所提高，當(dāng)然，這個代碼效率的提高可能還跟其他因素有關(guān)，比如 Gcc 還優(yōu)化了一些跟平臺相關(guān)的指令。

如果想看看代碼中各行被執(zhí)行的情況，可以直接看 fib.c.gcov 文件。這個文件的各列依次表示執(zhí)行次數(shù)、行號和該行的源代碼。次數(shù)有三種情況，如果一直沒有執(zhí)行，那么用 #### 表示；如果該行是注釋、函數(shù)聲明等，用 - 表示；如果是純粹的代碼行，那么用執(zhí)行次數(shù)表示。這樣我們就可以直接分析每一行的執(zhí)行情況。

gcov 也有一個圖形化接口 ggcov，是基于 gtk+ 的，適合 Gnome 桌面的用戶。

現(xiàn)在都已經(jīng)關(guān)注到代碼行了，實際上優(yōu)化代碼的前提是保證代碼的正確性，如果代碼還有很多 bug，那么先要 debug。不過下面的這些 "bug" 用普通的工具確實不太方便，雖然可能，不過這里還是把它們歸結(jié)為測試的內(nèi)容，并且這里剛好承接上 gcov 部分，gcov 能夠測試到每一行的代碼覆蓋情況，而無論是內(nèi)存訪問越界、緩沖區(qū)溢出還是內(nèi)存泄露，實際上是發(fā)生在具體的代碼行上的。

內(nèi)存訪問越界 catchsegv, libSegFault.so

"Segmentation fault" 是很頭痛的一個問題，估計“糾纏”過很多人。這里僅僅演示通過 catchsegv 腳本測試段錯誤的方法，其他方法見后面相關(guān)資料。

catchsegv 利用系統(tǒng)動態(tài)鏈接的 PRELOAD 機(jī)制（請參考man ld-linux），把庫 /lib/libSegFault.so 提前 load 到內(nèi)存中，然后通過它檢查程序運(yùn)行過程中的段錯誤。

$ cat test.c
#include <stdio.h>

int main(void)
{
    char str[10];

        sprintf(str, "%s", 111);

        printf("str = %s\n", str);
        return 0;
}
$ make test
$ LD_PRELOAD=/lib/libSegFault.so ./test  #等同于catchsegv ./test
*** Segmentation fault
Register dump:

 EAX: 0000006f   EBX: b7eecff4   ECX: 00000003   EDX: 0000006f
 ESI: 0000006f   EDI: 0804851c   EBP: bff9a8a4   ESP: bff9a27c

 EIP: b7e1755b   EFLAGS: 00010206

 CS: 0073   DS: 007b   ES: 007b   FS: 0000   GS: 0033   SS: 007b

 Trap: 0000000e   Error: 00000004   OldMask: 00000000
 ESP/signal: bff9a27c   CR2: 0000006f

Backtrace:
/lib/libSegFault.so[0xb7f0604f]
[0xffffe420]
/lib/tls/i686/cmov/libc.so.6(vsprintf+0x8c)[0xb7e0233c]
/lib/tls/i686/cmov/libc.so.6(sprintf+0x2e)[0xb7ded9be]
./test[0x804842b]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7dbd050]
./test[0x8048391]
...

從結(jié)果中可以看出，代碼的 sprintf 有問題。經(jīng)過檢查發(fā)現(xiàn)它把整數(shù)當(dāng)字符串輸出，對于字符串的輸出，需要字符串的地址作為參數(shù)，而這里的 111 則剛好被解釋成了字符串的地址，因此 sprintf 試圖訪問 111 這個地址，從而發(fā)生了非法訪問內(nèi)存的情況，出現(xiàn) “Segmentation Fault”。

緩沖區(qū)溢出 libsafe.so

緩沖區(qū)溢出是堆棧溢出（Stack Smashing），通常發(fā)生在對函數(shù)內(nèi)的局部變量進(jìn)行賦值操作時，超出了該變量的字節(jié)長度而引起對棧內(nèi)原有數(shù)據(jù)（比如 eip，ebp 等）的覆蓋，從而引發(fā)內(nèi)存訪問越界，甚至執(zhí)行非法代碼，導(dǎo)致系統(tǒng)崩潰。關(guān)于緩沖區(qū)的詳細(xì)原理和實例分析見《緩沖區(qū)溢出與注入分析》。這里僅僅演示該資料中提到的一種用于檢查緩沖區(qū)溢出的方法，它同樣采用動態(tài)鏈接的 PRELOAD 機(jī)制提前裝載一個名叫 libsafe.so 的庫，可以從這里獲取它，下載后，再解壓，編譯，得到 libsafe.so，

下面，演示一個非常簡單的，但可能存在緩沖區(qū)溢出的代碼，并演示 libsafe.so 的用法。

$ cat test.c
$ make test
$ LD_PRELOAD=/path/to/libsafe.so ./test ABCDEFGHIJKLMN
ABCDEFGHIJKLMN
*** stack smashing detected ***: ./test terminated
Aborted (core dumped)

資料[7]分析到，如果不能夠?qū)彌_區(qū)溢出進(jìn)行有效的處理，可能會存在很多潛在的危險。雖然 libsafe.so 采用函數(shù)替換的方法能夠進(jìn)行對這類 Stack Smashing 進(jìn)行一定的保護(hù)，但是無法根本解決問題，alert7 大蝦在資料[10]中提出了突破它的辦法，資料1111]提出了另外一種保護(hù)機(jī)制。

內(nèi)存泄露 Memwatch, Valgrind, mtrace

堆棧通常會被弄在一起叫，不過這兩個名詞卻是指進(jìn)程的內(nèi)存映像中的兩個不同的部分，棧（Stack）用于函數(shù)的參數(shù)傳遞、局部變量的存儲等，是系統(tǒng)自動分配和回收的；而堆（heap）則是用戶通過 malloc 等方式申請而且需要用戶自己通過 free 釋放的，如果申請的內(nèi)存沒有釋放，那么將導(dǎo)致內(nèi)存泄露，進(jìn)而可能導(dǎo)致堆的空間被用盡；而如果已經(jīng)釋放的內(nèi)存再次被釋放（double-free）則也會出現(xiàn)非法操作。如果要真正理解堆和棧的區(qū)別，需要理解進(jìn)程的內(nèi)存映像，請參考《緩沖區(qū)溢出與注入分析》

這里演示通過 Memwatch 來檢測程序中可能存在內(nèi)存泄露，可以從這里下載到這個工具。使用這個工具的方式很簡單，只要把它鏈接（ld）到可執(zhí)行文件中去，并在編譯時加上兩個宏開關(guān)-DMEMWATCH -DMW_STDIO。這里演示一個簡單的例子。

$ cat test.c 
#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);
}
$ gcc -DMEMWATCH -DMW_STDIO test.c memwatch.c -o test
$ cat memwatch.log
============= MEMWATCH 2.71 Copyright (C) 1992-1999 Johan Lindh =============

Started at Sat Mar  1 07:34:33 2008

Modes: __STDC__ 32-bit mwDWORD==(unsigned long)
mwROUNDALLOC==4 sizeof(mwData)==32 mwDataSize==32

double-free: <4> test.c(15), 0x80517e4 was freed from test.c(14)

Stopped at Sat Mar  1 07:34:33 2008

unfreed: <2> test.c(11), 512 bytes at 0x8051a14         {FE FE FE FE 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

通過測試，可以看到有一個 512 字節(jié)的空間沒有被釋放，而另外 512 字節(jié)空間卻被連續(xù)釋放兩次（double-free）。Valgrind 和 mtrace 也可以做類似的工作，請參考資料[4]，[5]和 mtrace 的手冊。

代碼調(diào)試

調(diào)試的方法很多，調(diào)試往往要跟蹤代碼的運(yùn)行狀態(tài)，printf 是最基本的辦法，然后呢？靜態(tài)調(diào)試方法有哪些，非交互的呢？非實時的有哪些？實時的呢？用于調(diào)試內(nèi)核的方法有哪些？有哪些可以用來調(diào)試匯編代碼呢？

靜態(tài)調(diào)試：printf + gcc -D（打印程序中的變量）

利用 Gcc 的宏定義開關(guān)（-D）和 printf 函數(shù)可以跟蹤程序中某個位置的狀態(tài)，這個狀態(tài)包括當(dāng)前一些變量和寄存器的值。調(diào)試時需要用 -D 開關(guān)進(jìn)行編譯，在正式發(fā)布程序時則可把 -D 開關(guān)去掉。這樣做比單純用 printf 方便很多，它可以避免清理調(diào)試代碼以及由此帶來的代碼誤刪除等問題。

$ cat test.c
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    int i = 0;

#ifdef DEBUG
        printf("i = %d\n", i);

        int t;
        __asm__ __volatile__ ("movl %%ebp, %0;":"=r"(t)::"%ebp");
        printf("ebp = 0x%x\n", t);
#endif

        _exit(0);
}
$ gcc -DDEBUG -g -o test test.c
$ ./test
i = 0
ebp = 0xbfb56d98

上面演示了如何跟蹤普通變量和寄存器變量的辦法。跟蹤寄存器變量采用了內(nèi)聯(lián)匯編。

不過，這種方式不夠靈活，我們無法“即時”獲取程序的執(zhí)行狀態(tài)，而 gdb 等交互式調(diào)試工具不僅解決了這樣的問題，而且通過把調(diào)試器拆分成調(diào)試服務(wù)器和調(diào)試客戶端適應(yīng)了嵌入式系統(tǒng)的調(diào)試，另外，通過預(yù)先設(shè)置斷點以及斷點處需要收集的程序狀態(tài)信息解決了交互式調(diào)試不適應(yīng)實時調(diào)試的問題。

交互式的調(diào)試（動態(tài)調(diào)試）：gdb（支持本地和遠(yuǎn)程）/ald（匯編指令級別的調(diào)試）

嵌入式系統(tǒng)調(diào)試方法 gdbserver/gdb

估計大家已經(jīng)非常熟悉 GDB（Gnu DeBugger）了，所以這里并不介紹常規(guī)的 gdb 用法，而是介紹它的服務(wù)器／客戶（gdbserver/gdb）調(diào)試方式。這種方式非常適合嵌入式系統(tǒng)的調(diào)試，為什么呢？先來看看這個：

$ wc -c /usr/bin/gdbserver 
56000 /usr/bin/gdbserver
$ which gdb
/usr/bin/gdb
$ wc -c /usr/bin/gdb
2557324 /usr/bin/gdb
$ echo "(2557324-56000)/2557324"  | bc -l
.97810210986171482377

gdb 比 gdbserver 大了將近 97%，如果把整個 gdb 搬到存儲空間受限的嵌入式系統(tǒng)中是很不合適的，不過僅僅 5K 左右的 gdbserver 即使在只有 8M Flash 卡的嵌入式系統(tǒng)中也都足夠了。所以在嵌入式開發(fā)中，我們通常先在本地主機(jī)上交叉編譯好 gdbserver/gdb。

如果是初次使用這種方法，可能會遇到麻煩，而麻煩通常發(fā)生在交叉編譯 gdb 和 gdbserver 時。在編譯 gdbserver/gdb 前，需要配置(./configure)兩個重要的選項：

--host，指定 gdb/gdbserver 本身的運(yùn)行平臺，
--target，指定 gdb/gdbserver 調(diào)試的代碼所運(yùn)行的平臺，

關(guān)于運(yùn)行平臺，通過 $MACHTYPE 環(huán)境變量就可獲得，對于 gdbserver，因為要把它復(fù)制到嵌入式目標(biāo)系統(tǒng)上，并且用它來調(diào)試目標(biāo)平臺上的代碼，因此需要把 --host 和 --target 都設(shè)置成目標(biāo)平臺；而 gdb 因為還是運(yùn)行在本地主機(jī)上，但是需要用它調(diào)試目標(biāo)系統(tǒng)上的代碼，所以需要把 --target 設(shè)置成目標(biāo)平臺。

編譯完以后就是調(diào)試，調(diào)試時需要把程序交叉編譯好，并把二進(jìn)制文件復(fù)制一份到目標(biāo)系統(tǒng)上，并在本地需要保留一份源代碼文件。調(diào)試過程大體如下，首先在目標(biāo)系統(tǒng)上啟動調(diào)試服務(wù)器：

$ gdbserver :port /path/to/binary_file
...

然后在本地主機(jī)上啟動gdb客戶端鏈接到 gdb 調(diào)試服務(wù)器，（gdbserver_ipaddress 是目標(biāo)系統(tǒng)的IP地址，如果目標(biāo)系統(tǒng)不支持網(wǎng)絡(luò)，那么可以采用串口的方式，具體看手冊）

$ gdb -q
(gdb) target remote gdbserver_ipaddress:2345
...

其他調(diào)試過程和普通的gdb調(diào)試過程類似。

匯編代碼的調(diào)試 ald

用 gdb 調(diào)試匯編代碼貌似會比較麻煩，不過有人正是因為這個原因而開發(fā)了一個專門的匯編代碼調(diào)試器，名字就叫做 assembly language debugger，簡稱 ald，你可以從這里下載到。

下載后，解壓編譯，我們來調(diào)試一個程序看看。

這里是一段非常簡短的匯編代碼：

.global _start 
_start:
        popl %ecx
        popl %ecx
        popl %ecx
        movb $10,12(%ecx) 
        xorl %edx, %edx
        movb $13, %dl
        xorl %eax, %eax 
        movb $4, %al 
        xorl %ebx, %ebx
        int $0x80 
        xorl %eax, %eax
        incl %eax        
        int $0x80

匯編、鏈接、運(yùn)行：

$ as -o test.o test.s
$ ld -o test test.o
$ ./test "Hello World"
Hello World

查看程序的入口地址：

$ readelf -h test | grep Entry 
  Entry point address:               0x8048054

接著用 ald 調(diào)試：

$ ald test
ald> display
Address 0x8048054 added to step display list
ald> n
eax = 0x00000000 ebx = 0x00000000 ecx = 0x00000001 edx = 0x00000000 
esp = 0xBFBFDEB4 ebp = 0x00000000 esi = 0x00000000 edi = 0x00000000 
ds  = 0x007B es  = 0x007B fs  = 0x0000 gs  = 0x0000 
ss  = 0x007B cs  = 0x0073 eip = 0x08048055 eflags = 0x00200292 

Flags: AF SF IF ID 

Dumping 64 bytes of memory starting at 0x08048054 in hex
08048054:  59 59 59 C6 41 0C 0A 31 D2 B2 0D 31 C0 B0 04 31    YYY.A..1...1...1
08048064:  DB CD 80 31 C0 40 CD 80 00 2E 73 79 6D 74 61 62    ...1.@....symtab
08048074:  00 2E 73 74 72 74 61 62 00 2E 73 68 73 74 72 74    ..strtab..shstrt
08048084:  61 62 00 2E 74 65 78 74 00 00 00 00 00 00 00 00    ab..text........

08048055                      59                   pop ecx

可見 ald 在啟動時就已經(jīng)運(yùn)行了被它調(diào)試的 test 程序，并且進(jìn)入了程序的入口 0x8048054，緊接著單步執(zhí)行時，就執(zhí)行了程序的第一條指令 popl ecx。

ald 的命令很少，而且跟 gdb 很類似，比如這個幾個命令用法和名字都類似 help,next,continue,set args,break,file,quit,disassemble,enable,disable 等。名字不太一樣但功能對等的有：examine 對 x, enter 對 set variable {int} 地址=數(shù)據(jù)。

需要提到的是：Linux 下的調(diào)試器包括上面的 gdb 和 ald，以及 strace 等都用到了 Linux 系統(tǒng)提供的 ptrace() 系統(tǒng)調(diào)用，這個調(diào)用為用戶訪問內(nèi)存映像提供了便利，如果想自己寫一個調(diào)試器或者想hack一下 gdb 和 ald，那么好好閱讀資料12和 man ptrace 吧。

如果確實需要用gdb調(diào)試匯編，可以參考：

Linux Assembly "Hello World" Tutorial, CS 200
Debugging your Alpha Assembly Programs using GDB

實時調(diào)試：gdb tracepoint

對于程序狀態(tài)受時間影響的程序，用上述普通的設(shè)置斷點的交互式調(diào)試方法并不合適，因為這種方式將由于交互時產(chǎn)生的通信延遲和用戶輸入命令的時延而完全改變程序的行為。所以 gdb 提出了一種方法以便預(yù)先設(shè)置斷點以及在斷點處需要獲取的程序狀態(tài)，從而讓調(diào)試器自動執(zhí)行斷點處的動作，獲取程序的狀態(tài)，從而避免在斷點處出現(xiàn)人機(jī)交互產(chǎn)生時延改變程序的行為。

這種方法叫 tracepoints（對應(yīng) breakpoint），它在 gdb 的用戶手冊里頭有詳細(xì)的說明，見 Tracepoints。

在內(nèi)核中，有實現(xiàn)了相應(yīng)的支持，叫 KGTP。

調(diào)試內(nèi)核

雖然這里并不會演示如何去 hack 內(nèi)核，但是相關(guān)的工具還是需要簡單提到的，這個資料列出了絕大部分用于內(nèi)核調(diào)試的工具，這些對你 hack 內(nèi)核應(yīng)該會有幫助的。

代碼優(yōu)化

這部分暫時沒有準(zhǔn)備足夠的素材，有待進(jìn)一步完善。

暫且先提到兩個比較重要的工具，一個是 Oprofile，另外一個是 Perf。

實際上呢？“代碼測試”部分介紹的很多工具是為代碼優(yōu)化服務(wù)的，更多具體的細(xì)節(jié)請參考后續(xù)資料，自己做實驗吧。

參考資料

VERIFICATION AND VALIDATION
difference between verification and Validation
Coverage Measurement and Profiling(覆蓋度測量和性能測試,Gcov and Gprof)
Valgrind Usage
Valgrind HOWTO
Using Valgrind to Find Memory Leaks and Invalid Memory Use
MEMWATCH
Mastering Linux debugging techniques
Software Performance Analysis
Runtime debugging in embedded systems
繞過libsafe的保護(hù)--覆蓋_dl_lookup_versioned_symbol技術(shù)
介紹Propolice怎樣保護(hù)stack-smashing的攻擊
Tools Provided by System：ltrace,mtrace,strace
Process Tracing Using Ptrace
Kernel Debugging Related Tools：KGDB, KGOV, KFI/KFT/Ftrace, GDB Tracepoint，UML, kdb
用Graphviz 可視化函數(shù)調(diào)用
Linux 段錯誤詳解
源碼分析之函數(shù)調(diào)用關(guān)系繪制系列
源碼分析：靜態(tài)分析 C 程序函數(shù)調(diào)用關(guān)系圖
源碼分析：動態(tài)分析 C 程序函數(shù)調(diào)用關(guān)系
源碼分析：動態(tài)分析 Linux 內(nèi)核函數(shù)調(diào)用關(guān)系
源碼分析：函數(shù)調(diào)用關(guān)系繪制方法與逆向建模
Linux 下緩沖區(qū)溢出攻擊的原理及對策
Linux 匯編語言開發(fā)指南
緩沖區(qū)溢出與注入分析(第一部分：進(jìn)程的內(nèi)存映像)
Optimizing C Code
Performance programming for scientific computing
Performance Programming
Linux Profiling and Optimization
High-level code optimization
Code Optimization

以上內(nèi)容是否對您有幫助：

在文檔使用的過程中是否遇到以下問題：

內(nèi)容錯誤
更新不及時
鏈接錯誤
缺少代碼/圖片示列
太簡單/步驟待完善
其他

更多建議：

提交建議

← 打造史上最小可執(zhí)行ELF文件(45字節(jié))

寫筆記

我要補(bǔ)充

查看完整版筆記

99re热这里只有精品视频,7777色鬼xxxx欧美色妇,国产成人精品一区二三区在线观看,内射爽无广熟女亚洲,精品人妻av一区二区三区

代碼測試、調(diào)試與優(yōu)化

代碼測試、調(diào)試與優(yōu)化

前言

代碼測試

測試程序的運(yùn)行時間 time

函數(shù)調(diào)用關(guān)系圖 calltree

性能測試工具 gprof & kprof

代碼覆蓋率測試 gcov & ggcov

內(nèi)存訪問越界 catchsegv, libSegFault.so

緩沖區(qū)溢出 libsafe.so

內(nèi)存泄露 Memwatch, Valgrind, mtrace

代碼調(diào)試

靜態(tài)調(diào)試：printf + gcc -D（打印程序中的變量）

交互式的調(diào)試（動態(tài)調(diào)試）：gdb（支持本地和遠(yuǎn)程）/ald（匯編指令級別的調(diào)試）

嵌入式系統(tǒng)調(diào)試方法 gdbserver/gdb

匯編代碼的調(diào)試 ald

實時調(diào)試：gdb tracepoint

調(diào)試內(nèi)核

代碼優(yōu)化

參考資料

代碼測試、調(diào)試與優(yōu)化

代碼測試、調(diào)試與優(yōu)化