我們從一個最簡單的C語言程式開始。原始檔main.c在 使用者目錄gdb資料夾下。

[email protected]:~/gdb$ cat main.c

int main()

{

    return 0;

};

然後將原始檔編譯為main（需要除錯選項-g），並將main.c移動到src/main.c下，然後對main進行除錯。

[email protected]:~/gdb$ gcc main.c -o main -g

[email protected]:~/gdb$ mv main.c src/main.c

[email protected]

(gdb) b main

Breakpoint 1 at 0x8048397: file main.c, line 3.

(gdb) list

1   main.c: 沒有那個檔案或目錄.

    in main.c

在gdb中，使用list命令檢視原始碼時，無法找到原始檔main.c。

探究

由於對DWARF除錯格式並不清晰，我本以為使用除錯選項編譯的可執行程式內部包含了原始檔的內容，這樣無論原始碼是否存在，可執行程式都可以被正常除錯。但是，從上邊的例子中可以看出，事實並非如此。

我們可以作一個簡單的推測：由於移動原始檔的位置後，gdb無法找到原始檔的位置，估計可執行檔案的除錯段內儲存的不是原始檔的內容，而是路徑資訊。

將main.c移動回來，重新編譯，生成目標檔案main.o，並檢視其段資訊。

[email protected]:~/gdb$ mv src/main.c main.c

[email protected]:~/gdb$ gcc -c main.c -o main.o -g

[email protected]:~/gdb$ objdump -s main.o

main.o:     file format elf32-i386

Contents of section .text:

 0000 5589e5b8 00000000 5dc3               U.......].     

……

Contents of section .debug_str:

 0000 6d61696e 2e63002f 686f6d65 2f666c6f  main.c./home/flo

0010 7269616e 2f676462 00474e55 20432034  rian/gdb.GNU C 4

 0020 2e342e35 006d6169 6e00                     .4.5.main.     

……

我們發現在.debug_str段內，有兩個很明顯的字串資訊。

（1）/home/florian/gdb：看起來很像原始檔所在的絕對路徑。

（2）main.c：顯而易見，是原始檔的名稱。

驗證

我們再把main.c移動到src目錄下，再次編譯，看看字串的資訊有何變化。

[email protected]:~/gdb$ mv main.c src/main.c

[email protected]:~/gdb$ gcc -c src/main.c -o main.o -g

[email protected]:~/gdb$ objdump -s main.o

main.o:     file format elf32-i386

Contents of section .text:

 0000 5589e5b8 00000000 5dc3               U.......].     

……

Contents of section .debug_str:

 0000 2f686f6d 652f666c 6f726961 6e2f6764  /home/florian/gd

 0010 6200474e 55204320 342e342e 35007372  b.GNU C 4.4.5.sr

 0020 632f6d61 696e2e63 006d6169 6e00     c/main.c.main. 

在.debug_str段內的兩個字串資訊發生了變化。

（1）/home/florian/gdb：可見該字串為執行gcc命令時的當前目錄的絕對路徑。

（2）src/main.c：該字串為原始檔相對於當前目錄的相對路徑。

將兩個目錄合併，便可以得到原始檔的絕對路徑：

/home/florian/gdb /src/main.c

結論

由此可見，使用除錯選項編譯生成的可執行檔案內並非儲存了原始檔的內容，而是原始檔的絕對路徑資訊。DWARF除錯格式（詳見這裡）定義的其他debug段內儲存了二進位制程式碼與原始檔行號的對應關係，這樣gdb的list命令工作時，實際是讀取可執行檔案內的行號資訊，並將原始檔的程式碼內容顯示出來。這也是為什麼將原始檔移動後，list命令資訊無法找到原始檔的原因。

從這裡，我們也可以清楚一個事實：當原始碼目錄的原始檔路徑發生變化後，如果需要對可執行檔案進行除錯，則必須重新編譯。

類似的問題不僅僅在gdb的list命令中存在，objdump –S命令用於交叉顯示反彙編程式碼與原始碼，同樣會受移動原始檔的影響。