gdbserver調(diào)試共享庫

　　在開發(fā)嵌入式系統(tǒng)時，調(diào)試往往是一大難題。面試過不少嵌入式linux工程師，當問及調(diào)試手段時，他們的調(diào)試手段一般是兩種：首先是在PC上的模擬環(huán)境中運行，若有問題，可以很方便的調(diào)試。其次，若在板子上運行時才出錯，就用printf輸出log信息，根據(jù)log信息定位錯誤。有少部分人用gdbserver調(diào)試板子上的程序，但問到如何在共享庫里設置斷點時，都說沒有辦法。

　　去年，Tinyx的一個內(nèi)存越界BUG，花了我2天時間。gcc的一個浮點數(shù)BUG讓我查了3天時間。這類BUG在PC上根本重現(xiàn)不了，在板子上用printf要花費大量的時間才能把錯誤的范圍縮小一點。后來想了想，與其花時間去加printf，還不如把gdbserver調(diào)試共享庫的問題解決了，可以為以后的調(diào)試節(jié)省不少時間。

　　在網(wǎng)上找了半天資料，沒有什么收獲，看來只好自己動手研究?；艘粋€周末的時間去研究gdbserver的運行方式。辦法是找到了，不過仍然有點麻煩，等有時間了，修改一下gdb的代碼，把這個過程自動化了。

　　先調(diào)試運行gdbserver，對gdbserver有了一些感性認識，然后研究linux-low.c中的代碼。原來，設置斷點只是在對應的內(nèi)存中寫入斷點指令（x86上為0xcc）。

　　gdbserver為什么不能在共享庫中設置斷點呢？設置斷點只是寫內(nèi)存，調(diào)試時，所有的代碼段都是可寫的，在exe中可以設置斷點，沒有理由不讓在共享庫中設置啊。所以這應該與是否是共享庫關系不大。

　　猜測可能是符號與地址對應關系有誤，如果你的本意為function1設置斷點，結果gdb搞錯了，設置一個毫不相干的地方，可能永遠都不會執(zhí)行到那里，這個斷點自然沒什么效果。

　　如果是這樣，有兩種方法可以解決：要么手動計算符號的地址，再設置斷點，當然這樣太累。另外就讓gdb自動對應起來。經(jīng)過反得嘗試，用下列方法可以在共享庫中設置斷點，雖然有點麻煩，還是可行的。

1.         準備工作，編寫下面幾個文件：

test.c:

#include

int test(int a, int b)

{
    int s = a + b;

    printf("%dn", s);

    return s;
}

main.c:

#include

extern int test(int a, int b);

int main(int argc, char* argv[])

{
    int s = test(10, 20);
    return s;
}

Makefile:

all: so main

so:

    gcc -g test.c -shared -o libtest.so

main:

    gcc -g main.c -L./ -ltest -o test.exe

clean:

rm -f *.exe *.so

（為了便于演示，整個過程在PC上測試，后來證實在實驗板上能夠正常工作）

2.         編譯并設置環(huán)境變量

make

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./

3.         運行gdbserver

gdbserver localhost:2000 ./test.exe

4.         運行gdb客戶端

gdb

symbol-file test.exe

target remote localhost:2000

b main

c

5.         查看libtest.so的代碼在內(nèi)存中的位置。

（從gdbserver的輸出或者用ps可以得到test.exe的進程ID，這里假設PID是11547）

cat /proc/11547/maps

輸出：

00624000-0063e000 r-xp 00000000 03:01 718192     /lib/ld-2.3.5.so

0063e000-0063f000 r-xp 00019000 03:01 718192     /lib/ld-2.3.5.so

0063f000-00640000 rwxp 0001a000 03:01 718192     /lib/ld-2.3.5.so

00642000-00766000 r-xp 00000000 03:01 718193     /lib/libc-2.3.5.so

00766000-00768000 r-xp 00124000 03:01 718193     /lib/libc-2.3.5.so

00768000-0076a000 rwxp 00126000 03:01 718193     /lib/libc-2.3.5.so

0076a000-0076c000 rwxp 0076a000 00:00 0

00bbe000-00bbf000 r-xp 00bbe000 00:00 0

00fcc000-00fcd000 r-xp 00000000 03:01 1238761    /root/test/gdbservertest/libtest.so

00fcd000-00fce000 rwxp 00000000 03:01 1238761    /root/test/gdbservertest/libtest.so

08048000-08049000 r-xp 00000000 03:01 1238765    /root/test/gdbservertest/test.exe

08049000-0804a000 rw-p 00000000 03:01 1238765    /root/test/gdbservertest/test.exe

b7f8a000-b7f8b000 rw-p b7f8a000 00:00 0

b7f99000-b7f9a000 rw-p b7f99000 00:00 0

bfd85000-bfd9a000 rw-p bfd85000 00:00 0          [stack]

由此可以知道：libtest.so的代碼在00fcc000-00fcd000之間。

6.         查看libtest.so的.text段在內(nèi)存中的偏移位置：

objdump -h libtest.so |grep .text

輸出：

9 .text         00000130  00000450  00000450  00000450  2**4

即偏移位置為0x00000450

7.         回到gdb窗口，加載libtest.so的符號表。

add-symbol-file libtest.so 0x00fcc450

(這里0x00fcc450 = 0x00fcc000 + 0x00000450)

8.         在共享庫的函數(shù)中設置斷點。

b test

9.         繼續(xù)調(diào)試，可以發(fā)現(xiàn)在共享庫中設置的斷點，能夠正常工作。