第一章 GDB入门：从历史到实战

各位同学好，我是你们这门课的老朋友。今天咱们聊聊GDB——这个在嵌入式开发里绕不开的调试利器。

说实话，我刚开始做嵌入式那会儿，对GDB是又爱又恨。爱的是它功能强大，恨的是它命令行操作太不友好。但用久了你会发现，GDB就像一把瑞士军刀，关键时刻总能救命。

1.1 GDB的历史与作用

GDB全称GNU Debugger，是Richard Stallman在1986年开发的。嗯，你没看错，就是那个自由软件之父。当时他写GDB是为了配合GCC编译器，打造一套完整的开源开发工具链。

我记得第一次接触GDB是在2008年，那时候还在用GDB 6.8版本。现在都到GDB 14了，但核心思想没变——让开发者能看清程序运行时到底发生了什么。

GDB能做什么？说白了就三件事：

• 观察：查看变量值、寄存器状态、内存内容
• 控制：单步执行、设置断点、改变程序流程
• 分析：回溯调用栈、分析崩溃原因、定位内存泄漏

你想想看，没有调试器的时候，排查bug只能靠printf大法。加一行打印，编译，运行，看输出，再改代码...循环往复，效率极低。GDB把这些都自动化了。

1.2 GDB在嵌入式开发中的核心地位

嵌入式开发和桌面开发有个本质区别——你没法直接在目标板上跑IDE。ARM Cortex-M芯片、RISC-V处理器，这些资源受限的平台上，GDB几乎是唯一的调试选择。

我在项目中遇到过最典型的情况：客户反馈设备偶尔死机，但本地测试怎么也复现不了。后来用GDB远程调试，在关键路径上设置条件断点，终于抓到了那个只在特定时序下触发的bug。

GDB在嵌入式领域的几个关键应用场景：

场景	说明	我的经验
裸机调试	无操作系统，直接调试硬件	配合JTAG/SWD调试器，查看外设寄存器
RTOS调试	FreeRTOS、RT-Thread等	查看任务栈、信号量状态
Linux内核调试	驱动开发、内核模块	用kgdb调试内核崩溃
交叉编译调试	PC上编译，目标板运行	需要配置sysroot和库路径

为什么GDB这么重要？因为嵌入式系统的调试手段太少了。没有屏幕可以打日志，没有键盘可以输入命令，甚至可能连串口都没有。GDB通过调试接口（JTAG/SWD）直接控制CPU，这才是真正的底层调试。

1.3 GDB的基本工作流程

GDB的工作流程，说白了就是「启动-控制-分析」三步走。咱们用一个最简单的例子来说明。

假设你有这么一段代码：

// test.c
#include <stdio.h>

int add(int a, int b) {
    return a + b;
}

int main() {
    int x = 10;
    int y = 20;
    int z = add(x, y);
    printf("z = %d\n", z);
    return 0;
}

编译时记得加-g选项：

gcc -g -o test test.c

然后启动GDB：

gdb ./test

这时候你就进入了GDB的交互界面。我个人习惯先设置几个断点：

(gdb) break main
(gdb) break add
(gdb) run

程序会在main函数入口停下来。然后你可以：

• next（或n）：单步执行，不进入函数
• step（或s）：单步执行，进入函数
• print x：查看变量x的值
• backtrace：查看调用栈
• continue：继续执行到下一个断点

我曾经犯过一个低级错误——在调试多线程程序时，用next跳过了线程创建函数，结果程序直接跑飞了。后来才意识到，多线程调试要用thread apply all bt查看所有线程的栈。

下面这张图展示了GDB的核心工作流程：

这张图把GDB的调试循环讲得很清楚。你启动GDB，设置断点，运行程序，然后在调试循环里反复观察和控制，直到找到问题根源，最后退出。

嗯，这里要注意一点：GDB的调试循环不是线性的。你可能需要多次运行、多次设置断点、反复查看变量。我调试复杂bug时，经常要重复几十次这个循环。

最后说个我自己的习惯：每次调试完，我会用save breakpoints命令把断点保存下来。下次调试直接source加载，省得重新设置。这个小技巧帮我省了不少时间。