GDB（GNU Debugger）的調試功能非常強大，甚至可以和Visual C++、Visual Basic、Jbuilder等開發工具的調試器相媲美。但GDB的缺點是沒有圖形調試界面。
前提
運行命令gcc –g hello.c -o hello對hello.c進行編譯，其中參數g的作用是把調試信息加入生成的test可執行文件中，否則GDB就無法對hello進行調試。
- 進入調試
運行 gdb test
- 查看源代碼
(gdb) l //list顯示10行代碼，再運行一次l就會顯示下10行的代碼。方便源代碼的閱讀。
- 設置斷點
斷點是調試程序的重要方法，通過斷點我們可以知道程序每一步的執行情況（如當前變量的值，函數是否調用等）。在GDB中通過命令b進行斷點設置。如下所示：
(gdb) b 15 //breakpoint可以看到命令b在程序的低15行進行了第一個斷點的設置，並顯示了改斷點在內存中的物理地址。
- 查看斷點的情況
（gdb) info b - 運行程序
（gdb) r
B中通過命令”r”來運行程序。gdb默認從代碼的首行開始運行(也可以通過命令“r 行數”的方式指定行數開始運行。如果程序有斷點，則程序會在斷點的前一行暫停運行。
- 查看變量值
（gdb) p n - 繼續運行程序
（gdb) c查看當前程序的運行情況後，使用命令“c”就可以繼續將程序運行下去。
- 單步運行
在GDB中通過命令”s“（step的縮寫）和”n“（next的縮寫）讓程序一步一步的往下運行。其中s可以發生函數調用時進入函數內部運行，而n不會進入到函數內部運行。
工程管理器
在實際的開發過程中，僅僅通過使用 gcc 命令對程序進行編譯是非常低效的。原因主要有以下兩點。 1）程序往往是由多個源文件組成的，源文件的個數越多，那麼gcc的命令行就會越長。此外，各種編譯規則也會加大gcc命令行的複雜度。所以在開發調試程序的過程中，通過輸入 gcc命令行來編譯程序是很麻煩的。 2）在程序的整個開發過程中，調試的工作量佔到了整體工作量的 70%以上。在調試程序的過程中，每次調試一般只會修改部分源文件。而在使用gcc命令行編譯程序時，gcc會把那些沒有被修改的源文件一起編譯，這樣就會影響編譯的總體效率。
Make工程管理器的優越性具體體現在以下兩個方面。
（1）使用方便 通過命令“make”就可以啓動Make工程管理器對程序進行編譯，所以不再需要每次都輸入gcc命令行。
（2）調試效率高 爲了提高編譯程序的效率，Make會檢查每個源文件的修改時間（時間戳）。只有在上次編譯之後被修改的源文件纔會在接下來的編譯過程中被編譯和鏈接，這樣就能避免多餘的編譯工作量。
Makefile 文件由以下三項基本內容組成。
1） 需要生成的目標文件（target file）。
2） 生成目標文件所需要的依賴文件（dependency file）。
3） 生成目標文件的編譯規則命令行（command）。
這三項內容按照如下格式進行組織：
target file ：dependency file command
Makefile規定在書寫command命令行前必須加一個鍵。
舉個栗子：vim hello.c創建hello.c文件
#include<stdio.h>
int main()
{
printf("hello world\n");
return 0;
}vim Makefile創建工程管理器
//定義變量
CC = gcc
target = hello
object = hello.o
//Make中的變量用$(變量名)表示
$(target) : $(object)
$(CC) $(object) -o $(target)
//這是<Tab>鍵
.PHONY : clean
clean :
rm -rf hello *.o
第一次make時執行
gcc -c -o hello.o hello.c
gcc hello.o -o hello如果修改了源文件，則重新運行，若沒有，則顯示
make: “hello”是最新的。