1. 深度linux V20如何安裝gdb，如何用gdb調試程序、用gdb設置斷點刪除斷點、gdb自動顯示變數值、看內存值
因本人通過幾個小時的時間才解決這個問題，希望我的答案能節省大部分初學者在gdb上的時間。我也是今天才接觸gdb，以下是有關深度linux V20的gdb調試問題的初步總結：
安裝gdb方式，sudo apt-get install gdb ，有ok點擊ok安裝，直到安裝結束。
gcc -g aa.c之後才能調試a.out文件。(aa.c表示你的源文件)
用法gdb a.out或者gdb進入後file a.out
l N是查看N行附近的代碼，直接l是顯示接下去的代碼。r運行過程中遇到斷點，按l則顯示斷點附近代碼。
l 函數名是查看函數名里邊的代碼
q退出調試。
p 變數，查看變數即時值。
r運行。
n單步執行。
s單步執行-進入函數。
c連續多步運行，直到下個斷點（循環的下一次斷點）暫停。
b N第N行設置斷點。
b 函數名，在函數名的入口處設置斷點。
b 文件名:行號，在指定文件名行號設置斷點。其中文件名是源文件的文件名。
(條件斷點)b 行號 if 變數==N，表示該行號的斷點必須滿足變數==N的條件下才停下來。
ignore 斷點編號 N，表示該斷點編號在接下來的運行過程中忽略N次，即第N+1次該斷點才會停下來。
info break顯示全部斷點。簡寫i b
delete 1-3刪除編號為1到3的斷點。簡寫 d 1-3。d 4隻刪除編號為4的斷點。
delete break刪除所有斷點。無法簡寫
clear 20刪除20行斷點。
運行中disable break n 禁用斷點號為n的斷點。enable break n 使能斷點為n的斷點號重新啟用。其中break可以簡寫為b
display {var1,var2,var3}自動顯示var1～3變數的值。要刪除display則用delete display N，N表示display的編號，如果不加N則表示刪除全部的display。如果要自動顯示數組內容，用display 數組名。注意：display需要r之後才能設置。
watch {var1,var2,var3}自動跟蹤改變的值，只要有改變才顯示watch。要刪除watch，用d N，N代表watch編號，用i b可以查看該編號。注意：watch需要r之後才能設置。
gdb死循環程序按鍵盤ctrl+c可結束程序
****************
要查看內存地址的內容用x /nfu 內存地址。以下是n、f、u的解釋
其中n表示要顯示多少個內存單元。
f表示顯示方式, 可取如下值
x 按十六進制格式顯示變數。
d 按十進制格式顯示變數。
u 按十進制格式顯示無符號整型。
o 按八進制格式顯示變數。
t 按二進制格式顯示變數。
a 按十六進制格式顯示變數。
i 指令地址格式
c 按字元格式顯示變數。
f 按浮點數格式顯示變數。
u表示一個地址單元的長度
b表示單位元組，
h表示雙位元組，
w表示四位元組，
g表示八位元組
*****************
2. linux中怎麼使用gdb調試進程有dettach
在2.5.60版Linux內核及以後，GDB對使用fork/vfork創建子進程的程序提供了follow-fork-mode選項來支持多進程調試。 follow-fork-mode的用法為： set follow-fork-mode [parentchild] parent: fork之後繼續調試父進程，子進程不受影響。 child: fork之後調試子進程，父進程不受影響。 因此如果需要調試子進程，在啟動gdb後： (gdb) set follow-fork-mode child並在子進程代碼設置斷點。 此外還有detach-on-fork參數，指示GDB在fork之後是否斷開（detach）某個進程的調試，或者都交由GDB控制： set detach-on-fork [onoff] on: 斷開調試follow-fork-mode指定的進程。 off: gdb將控制父進程和子進程。follow-fork-mode指定的進程將被調試，另一個進程置於暫停（suspended）狀態。 注意，最好使用GDB 6.6或以上版本，如果你使用的是GDB6.4，就只有follow-fork-mode模式。 follow-fork-mode/detach-on-fork的使用還是比較簡單的，但由於其系統內核/gdb版本限制，我們只能在符合要求的系統上才能使用。而且，由於follow-fork-mode的調試必然是從父進程開始的，對於fork多次，以至於出現孫進程或曾孫進程的系統，例如上圖3進程系統，調試起來並不方便。 Attach子進程 眾所周知，GDB有附著（attach）到正在運行的進程的功能，即attach <pid>命令。因此我們可以利用該命令attach到子進程然後進行調試。 例如我們要調試某個進程RIM_Oracle_Agent.9i，首先得到該進程的pid [root@tivf09 tianq]# ps -efgrep RIM_Oracle_Agent.9i nobody 6722 6721 0 05:57 ? 00:00:00 RIM_Oracle_Agent.9i root 7541 27816 0 06:10 pts/3 00:00:00 grep -i rim_oracle_agent.9i通過pstree可以看到，這是一個三進程系統，oserv是RIM_Oracle_prog的父進程，RIM_Oracle_prog又是RIM_Oracle_Agent.9i的父進程。 [root@tivf09 root]# pstree -H 6722通過 pstree 察看進程 啟動GDB，attach到該進程 用 GDB 連接進程 現在就可以調試了。一個新的問題是，子進程一直在運行，attach上去後都不知道運行到哪裡了。有沒有辦法解決呢？ 一個辦法是，在要調試的子進程初始代碼中，比如main函數開始處，加入一段特殊代碼，使子進程在某個條件成立時便循環睡眠等待，attach到進程後在該代碼段後設上斷點，再把成立的條件取消，使代碼可以繼續執行下去。 至於這段代碼所採用的條件，看你的偏好了。比如我們可以檢查一個指定的環境變數的值，或者檢查一個特定的文件存不存在。以文件為例，其形式可以如下： void debug_wait(char *tag_file) { while(1) { if (tag_file存在) 睡眠一段時間; else break; } }當attach到進程後，在該段代碼之後設上斷點，再把該文件刪除就OK了。當然你也可以採用其他的條件或形式，只要這個條件可以設置/檢測即可。 Attach進程方法還是很方便的，它能夠應付各種各樣復雜的進程系統，比如孫子/曾孫進程，比如守護進程（daemon process），唯一需要的就是加入一小段代碼。 GDB wrapper 很多時候，父進程 fork 出子進程，子進程會緊接著調用 exec族函數來執行新的代碼。對於這種情況，我們也可以使用gdb wrapper 方法。它的優點是不用添加額外代碼。 其基本原理是以gdb調用待執行代碼作為一個新的整體來被exec函數執行，使得待執行代碼始終處於gdb的控制中，這樣我們自然能夠調試該子進程代碼。 還是上面那個例子，RIM_Oracle_prog fork出子進程後將緊接著執行RIM_Oracle_Agent.9i的二進制代碼文件。我們將該文件重命名為RIM_Oracle_Agent.9i.binary，並新建一個名為RIM_Oracle_Agent.9i的shell腳本文件，其內容如下： [root@tivf09 bin]# mv RIM_Oracle_Agent.9i RIM_Oracle_Agent.9i.binary [root@tivf09 bin]# cat RIM_Oracle_Agent.9i #!/bin/sh gdb RIM_Oracle_Agent.binary當fork的子進程執行名為RIM_Oracle_Agent.9i的文件時，gdb會被首先啟動，使得要調試的代碼處於gdb控制之下。
3. Linux內核調試工具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的控制權重新交還給內核。KGDB補丁給內核添加以下3個部件：
(1 ) GDB stub
GDB stub被稱為調試插樁（簡稱為stub)，是KGDB調試器的核心。它是Linux內核中的一小段代碼，用來處理主機上: GDB發來的各種請求;並且在內核處於被調試狀態時，控制目標機板上的處理器。
(2）修改異常處理函數
當這個異常發生時，內核將控制權交給KGDB調試器，程序進入KGDB提供的異常處理函數中。在裡面，可以分析程序的各種情況。
(3)串口通信
GDB和 stub之間通過GDB串列協議進行通信。它是一種基於消息的ASCII 碼協議，包含了各種調試命令。除串口外，也可以使用網卡進行通信。以設置內核斷點為例說明KGDB與GDB之間的工作過程。設置斷點時，KGDB修改內核代碼，將斷點位置的指令替換成一條異常指令(在ARM中這是一條未定義的指令)。當執行到斷點時發生異常，控制權轉移到stub 的異常處理函數中。此時，stub的任務就是使用GDB串列通信協議將當前環境傳送給GDB，然後從GDB處接收命令，GDB命令告訴stub下一步該做什麼。當stub收到繼續執行的命令時，將恢復原來替換的指令、恢復程序的運行環境，把對CPU的控制權重新交還給內核。
4. 如何使用gdb調試linux kernel
gdb是用來調試二進製程序的，不能調試python腳本。 python自帶pdb模塊，可以用來調試自己的腳本。 使用python -m pdb ，交互方式，命令與gdb類似。
5. gdb調試(ARM+Linux)中的gdbserver該怎麼理解呢
1、ARM硬體內核嵌入了能夠響應J－Link命令的調試模塊（用戶無法修改，也不需要額外燒錄程序）；
2、在調試過程是，由ARM內嵌的調試模塊來執行和響應Linux下的gdb調試軟體（工具），所以有些人把它稱為gdbserver；
3、而linux中的軟體很多都是伺服器+用戶的模式（不明白的可以直接忽略這個表述），Linux中的gdb在自己的軟體架構有一個虛擬的伺服器（就是上圖中的GDB Server），其與博客上的gdbserver不是一個東東；
4、我個人也不認同有些博客中的那種說法，但也不能說他們是錯的，因為從宏觀的角度講，ARM硬體內核嵌入調試模塊正是為gdb服務的，因此稱之為gdbserver也有些道理，只不過這樣一來，給造成不必要的誤解！
******希望我的解釋對你有幫助！
6. Linux：如何使用gdb調試多進程多線程程序
follow-fork-mode
在2.5.60版Linux內核及以後，GDB對使用fork/vfork創建子進程的程序提供了follow-fork-mode選項來支持多進程調試。
follow-fork-mode的用法為：
set follow-fork-mode [parent|child]
parent: fork之後繼續調試父進程，子進程不受影響。
child: fork之後調試子進程，父進程不受影響。
因此如果需要調試子進程，在啟動gdb後：
(gdb) set follow-fork-mode child
並在子進程代碼設置斷點。
此外還有detach-on-fork參數，指示GDB在fork之後是否斷開（detach）某個進程的調試，或者都交由GDB控制：
set detach-on-fork [on|off]
on: 斷開調試follow-fork-mode指定的進程。
off: gdb將控制父進程和子進程。follow-fork-mode指定的進程將被調試，另一個進程置於暫停（suspended）狀態。
注意，最好使用GDB 6.6或以上版本，如果你使用的是GDB6.4，就只有follow-fork-mode模式。
follow-fork-mode/detach-on-fork的使用還是比較簡單的，但由於其系統內核/gdb版本限制，我們只能在符合要求的系統上才能使用。而且，由於follow-fork-mode的調試必然是從父進程開始的，對於fork多次，以至於出現孫進程或曾孫進程的系統，例如上圖3進程系統，調試起來並不方便。
7. linux內核漏洞分析實戰 看看專家是怎麼一步步用gdb kgdb調試linux內核驅動的
Linux內核調試方法
kdb：只能在匯編代碼級進行調試；
優點是不需要兩台機器進行調試。
gdb：在調試模塊時缺少一些至關重要的功能，它可用來查看內核的運行情況，包括反匯編內核函數。
kgdb：能很方便的在源碼級對內核進行調試，缺點是kgdb只能進行遠程調試，它需要一根串口線及兩台機器來調試內核(也可以是在同一台主機上用vmware軟體運行兩個操作系統來調試)
printk() 是調試內核代碼時最常用的一種技術。在內核代碼中的特定位置加入printk() 調試調用，可以直接把所關心的信息打列印到屏幕上，從而可以觀察程序的執行路徑和所關心的變數、指針等信息。 Linux 內核調試器（Linux kernel debugger，kdb）是 Linux 內核的補丁，它提供了一種在系統能運行時對內核內存和數據結構進行檢查的辦法。Oops、KDB在文章掌握 Linux 調試技術有詳細介紹，大家可以參考。 Kprobes 提供了一個強行進入任何內核常式，並從中斷處理器無干擾地收集信息的介面。使用 Kprobes 可以輕松地收集處理器寄存器和全局數據結構等調試信息，而無需對Linux內核頻繁編譯和啟動，具體使用方法，請參考使用 Kprobes 調試內核。
/proc文件系統
在 /proc 文件系統中，對虛擬文件的讀寫操作是一種與內核通信的手段，要查看內核回環緩沖區中的消息，可以使用 dmesg 工具（或者通過 /proc 本身使用 cat /proc/kmsg 命令）。清單 6 給出了 dmesg 顯示的最後幾條消息。
清單 6. 查看來自 LKM 的內核輸出
[root@plato]# dmesg | tail -5
cs: IO port probe 0xa00-0xaff: clean.
eth0: Link is down
eth0: Link is up, running at 100Mbit half-plex
my_mole_init called. Mole is now loaded.
my_mole_cleanup called. Mole is now unloaded.
可以在內核輸出中看到這個模塊的消息。現在讓我們暫時離開這個簡單的例子，來看幾個可以用來開發有用 LKM 的內核 API。
調試工具
使用調試器來一步步地跟蹤代碼，查看變數和計算機寄存器的值。在內核中使用互動式調試器是一個很復雜的問題。內核在它自己的地址空間中運行。許多用戶空間下的調試器所提供的常用功能很難用於內核之中，比如斷點和單步調試等。
8. 如何在安卓系統上使用arm-linux-gdb調試內核
1，先下載最新版本的gdb源代碼包，我使用的是gdb-7.6.tar.gz，使用tar命令進行解包（tar -xvzf gdb-7.6.tar.gz）,cd進gdb-7.6/gdb目錄，使用vi找到remote.c中的如下代碼:
if(buf_len > 2 * rsa->sizeof_g_packet)
error(_("Remote 'g' packet reply is too long: %s"),rs->buf);
將上面兩行注釋掉，添加如下代碼
if(buf_len > 2 * rsa->sizeof_g_packet)
{
rsa->sizeof_g_packet = buf_len;
for(i = 0; i < gdbarch_num_regs(gdbarch); i++)
{
if(rsa->regs[i].pnum == -1)
continue;
if(rsa->regs[i].offset >= rsa->sizeof_g_packet)
rsa->regs[i].in_g_packet = 0;
else
rsa->regs[i].in_g_packet = 1;
}
}
使用如下命令對代碼進行配置、編譯和安裝
./configure --target=arm-linux --prefix=/usr/local/arm-gdb -v
make
make install
2，gdbserver使用android4.2模擬器中自帶的版本（v7.1）
3，將NDK編譯好的C/C++可執行程序，上傳到模擬器中/data/test目錄下，假設可執行程序的名稱為testHello。
4，使用命令：gdbserver :7000 /data/test/testHello 啟動模擬器端的調試。
5，啟動arm-linux-gdb之前，使用vi打開~/.bash_profile文件，在其中添加：
export PATH=$PATH:/usr/local/arm-gdb/bin,以便在程序的其他目錄可以直接啟動arm-linux-gdb程序
6，cd至ndk編譯好的testHello文件所在目錄
7，使用如下命令進行埠映射：adb forward tcp:7000 tcp:7000,將模擬器的7000埠和本機的7000埠進行映射
8，使用命令：arm-linux-gdb testHello啟動gdb調試
9，使用target remote :7000 鏈接模擬器中gdbserver啟動的服務。
10，自此，我們就可以使用gdb命令進行代碼調試了。
9. 嵌入式Linux的GDB遠程調試如何實現呢
有道啟新嵌入式研究院——遠程調試環境由宿主機GDB和目標機調試stub共同構成，兩者通過串口或TCP連接。使用GDB標准遠程串列協議協同工作，實現對目標機上的系統內核和上層應用的監控和調試功能。調試stub是嵌入式系統中的一段代碼，作為宿主機GDB和目標機調試程序間的一個媒介而存在。
就目前而言，嵌入式Linux系統中，主要有三種遠程調試方法，分別適用於不同場合的調試工作：用ROM Monitor調試目標機程序、用KGDB調試系統內核和用gdbserver調試用戶空間程序。這三種調試方法的區別主要在於，目標機遠程調試stub的存在形式的不同，而其設計思路和實現方法則是大致相同的。
而我們最常用的是調試應用程序。就是採用gdb+gdbserver的方式進行調試。在很多情況下，用戶需要對一個應用程序進行反復調試，特別是復雜的程序。採用GDB方法調試，由於嵌入式系統資源有限性，一般不能直接在目標系統上進行調試，通常採用gdb+gdbserver的方式進行調試。Gdbserver在目標系統中運行，gdb則在宿主機上運行。
要進行GDB調試，目標系統必須包括gdbserver程序，宿主機也必須安裝gdb程序。一般linux發行版中都有一個可以運行的gdb，但開發人員不能直接使用該發行版中的gdb來做遠程調試，而要獲取gdb的源代碼包，針對arm平台作一個簡單配置，重新編譯得到相應gdb.gdb的源代碼包可以從http://ftp.cs.pu.e.tw/Linux/sourceware/gdb/releases/下載，最新版本為gdb-6.4.下載到某個目錄，筆者下載到自己的用戶目錄：/home/vicky.下載完後，進入/home/vicky目錄，配置編譯步驟如下：
#tar jxvf gdb-6.4-tar-bz2
#cd gdb-6.4
#./configure --target=arm-linux --prefix=/usr/local/arm-gdb -v
#make
(這一步的時候可能會有問題，提示一個函數中（具體函數名不記得了）parse error，就是unsigned前邊多了一個」}」,你用vi進入那一行把它刪掉就行了。)
#make install
#export PATH=$PATH:/usr/local/arm-gdb
進入gdbserver目錄：
#./configure --target=arm-linux –host=arm-linux
#make CC=/usr/local/arm/2.95.3/bin/arm-linux-gcc
(這一步要指定arm-linux-gcc的位置，可能跟你的不一樣)
沒有錯誤的話就在gdbserver目錄下生成gdbserver可執行文件，把它燒寫到flash的根文件系統分區，或通過nfs mount的方式都可以。只要保證gdbserver能在開發板上運行就行。
下面就可以用gdb+gdbserver調試我們開發板上的程序了。在目標板上運行gdbserver，其實就是在宿主機的minicom下，我的red hat linux裝在vmware下的。我是在minicom下#mount 192.168.2.100：/ /tmp後做的（這里參數-o nolock可以不加，不加這一步執行得反而更快些），hello和gdbserver都是位於linux根目錄下，把主機根目錄掛在到開發板的/tmp目錄下。
要進行gdb調試，首先要在目標系統上啟動gdbserver服務。在gdbserver所在目錄下輸入命令：
(minicom下)
#cd /tmp
#./gdbserver 192.168.2.100:2345 hello
192.168.2.100為宿主機IP，在目標系統的2345埠開啟了一個調試進程，hello為要調試的程序。
出現提示：
Process /tmp/hello created: pid=80
Listening on port 2345
(另一個終端下)
#cd /
#export PATH=$PATH:/usr/local/arm-gdb/bin
#arm-linux-gdb hello
(gdb) target remote 192.168.2.223:2345
（192.168.2.223為開發板IP）
出現提示：
Remote debugging using 192.168.2.223:2345
[New thread 80]
[Switching to thread 80]
0x40002a90 in ??()
同時在minicom下提示：
Remote debugging from host 192.168.2.100
(gdb)
連接成功，這時候就可以輸入各種gdb命令如list、run、next、step、break等進行程序調試了。
以上針對通過nfs mount和tftp的方式，只能在主機上調試好後下載到開發板上運行，如果有錯誤要反復這個過程，繁瑣不說，有些程序只能在開發板上調試。所以筆者採用了gdbserver的遠程調試方式。希望對大家調試程序有用！