2. GDB入门：从历史到实战启动
调试器这东西，说白了就是嵌入式开发者的「第二双眼睛」。尤其搞ARM Cortex-M，没有趁手的调试工具，你连程序跑飞在哪都不知道。今天咱们就来聊聊GDB——这个在调试界活了三十多年的老家伙。
2.1 GDB的历史：一个传奇的诞生
GDB全称GNU Debugger，是Richard Stallman在1986年发起的GNU项目的一部分。我刚开始接触嵌入式时，用的还是IDE自带的调试器，后来第一次在命令行敲下gdb，那种「一切尽在掌控」的感觉，至今难忘。
为什么GDB能活这么久？三个原因：
- 开源免费——GNU通用公共许可证，随便用
- 跨平台——从Linux到Windows，从x86到ARM，几乎全覆盖
- 可扩展——支持Python脚本，你想怎么玩都行
我记得2015年做一个Cortex-M4的项目，IDE自带的调试器死活连不上目标板。最后靠GDB + OpenOCD硬是调通了，从那以后，我再也没完全依赖过IDE的调试功能。
2.2 GDB的核心功能：它能帮你做什么？
GDB不是那种「一键调试」的傻瓜工具。它更像一把瑞士军刀，每个功能都对应一个具体的调试场景。下面这张图帮你快速建立整体认知：
这四大功能，基本覆盖了日常调试的90%场景。我个人的经验是：断点 + 单步 + 变量查看，这三板斧就能解决大部分问题。寄存器操作更多用在底层启动代码和中断处理中。
2.3 GDB的安装：不同平台怎么搞？
安装GDB其实很简单，但要注意——调试ARM Cortex-M需要交叉编译版本的GDB。你拿x86的GDB去调ARM，那肯定不行。
| 平台 | 安装命令 | 说明 |
|---|---|---|
| Ubuntu/Debian | sudo apt install gdb-multiarch |
推荐，支持多架构 |
| Windows | 下载ARM GCC工具链 | 自带arm-none-eabi-gdb |
| macOS | brew install arm-none-eabi-gdb |
需要安装Homebrew |
| 源码编译 | ./configure --target=arm-none-eabi |
定制化需求 |
我的建议：在Linux上直接用gdb-multiarch，它不仅能调ARM，还能调RISC-V、MIPS，一个工具搞定所有嵌入式调试。Windows用户直接装ARM GCC工具链，里面自带的arm-none-eabi-gdb就是专门调Cortex-M的。
2.4 启动GDB：三种方式，你选哪种？
安装好之后，怎么启动？有三种常见方式：
方式一：直接启动（本地调试）
gdb-multiarch ./my_program.elf这种方式适合调试本地编译的程序。但在Cortex-M开发中，我们很少这么用——因为程序跑在开发板上，不是PC上。
方式二：远程调试（嵌入式标准姿势）
gdb-multiarch ./firmware.elf
(gdb) target remote localhost:3333这才是嵌入式调试的常态。GDB作为客户端，通过TCP连接到调试代理（比如OpenOCD、JLink GDB Server）。端口3333是OpenOCD的默认端口，JLink默认用2331。
方式三：扩展远程调试（通过GDB Server）
arm-none-eabi-gdb ./firmware.elf
(gdb) target extended-remote localhost:3333extended-remote比remote多了文件传输、多进程支持等功能。我个人习惯用extended-remote，因为它在调试过程中可以重新加载程序，不用退出GDB。
曾经踩过的坑：我第一次用GDB连Cortex-M4时，忘了启动OpenOCD就直接敲target remote，结果GDB一直卡在「Connecting...」。后来才反应过来——GDB只是客户端，你得先让调试代理跑起来。顺序是：先启动OpenOCD/JLink，再启动GDB连接。
2.5 启动后的第一件事：验证连接
连接成功后，我通常会做这几步验证：
- 查看目标状态——
info target，确认GDB识别了正确的芯片 - 查看寄存器——
info registers，看看PC指针是不是在复位向量附近 - 查看内存——
x/8xw 0x08000000，检查Flash起始地址的内容 - 尝试单步——
stepi，看PC是否正常移动
如果以上都正常，恭喜你，GDB已经和你的Cortex-M成功「握手」了。
快速验证命令清单：
(gdb) info target # 查看目标设备
(gdb) info registers # 查看寄存器
(gdb) x/8xw 0x08000000 # 查看Flash起始8个字
(gdb) stepi # 单步执行一条指令
(gdb) continue # 恢复运行2.6 一个小习惯：使用.gdbinit文件
每次启动GDB都要敲一堆命令，烦不烦？我习惯在项目根目录放一个.gdbinit文件，GDB启动时会自动执行里面的命令：
# .gdbinit 示例
target extended-remote localhost:3333
monitor reset halt
load
break main
continue这样每次启动GDB，它会自动连接、复位、加载程序、停在main函数。省去了重复敲命令的麻烦。
注意：GDB默认会加载~/.gdbinit（用户目录）和当前目录的.gdbinit。如果当前目录没有，它不会报错，只是跳过。你可以用-x参数指定其他初始化文件：gdb -x my_init.gdb ./firmware.elf。
2.7 本章小结
GDB不是那种「装好就能用」的工具，它需要你理解它的工作模式——客户端/服务器架构。记住：GDB只管调试逻辑，和硬件通信是调试代理（OpenOCD/JLink）的事。搞清楚了这一点，后面所有的操作都会顺理成章。