GDB调试C++程序核心三步：编译加-g、启动GDB、设断点运行；关键在明确停靠位置、检查数据状态、控制执行流程。
直接用 GDB 调试 C++ 程序，核心就三步：编译带调试信息、启动 GDB、下断点跑起来。关键不是记命令，而是搞清“在哪停、怎么查、怎么走”。
编译时必须加 -g 参数
不加 -g，GDB 看不到变量、函数名、行号，等于盲调。哪怕用了 -O2 优化，也建议保留 -g（但注意：过度优化可能让源码和汇编错位，初学建议先用 -O0）。
- 正确写法： g++ -g -o myapp main.cpp utils.cpp
- 错误写法： g++ -o myapp main.cpp（GDB 启动后会提示 "No debugging symbols found"）
- 如果用 CMake，确保 set(CMAKE_BUILD_TYPE Debug) 或手动加 -DCMAKE_CXX_FLAGS="-g"
常用 GDB 启动与运行命令
启动后别急着 run，先确认环境是否就绪。
- gdb ./myapp —— 加载程序（不运行）
- gdb ./myapp core —— 用 core 文件分析崩溃现场
- run 或 r —— 开始执行（可跟参数：r --input test.txt）
- kill —— 终止当前调试中的程序
- quit 或 q —— 退出 GDB
断点和单步：精准控制执行流
断点不是越多越好，关键是停在你想看的地方：函数入口、可疑逻辑前、对象构造/析构时。
立即学习“C++免费学习笔记（深入）”；
- break main —— 在 main 函数第一行设断点
- break MyClass::doWork —— 断在类成员函数（支持重载，必要时加参数类型）
- break file.cpp:25 —— 在指定文件第 25 行设断点
- next（n）—— 下一行（不进入函数）
- step（s）—— 进入函数内部（遇到函数调用就跳进去）
- finish —— 执行完当前函数，停在它的返回点
查看数据：变量、内存、调用栈
停住之后，重点是验证“程序状态是否符合预期”。
- print var_name（p var_name）—— 查变量值（支持 p *ptr、p arr@10 打印数组前 10 个）
- info locals —— 显示当前栈帧所有局部变量
- bt（backtrace）—— 看函数调用链，崩溃时第一时间输它
- frame 2 —— 切到第 2 层调用栈，再用 p 查那层的变量
- x/4dw &i —— 以“4 个有符号十进制整数”格式查看变量 i 的内存（适合查越界、未初始化）
基本上就这些。不复杂但容易忽略的是：每次改代码后记得重新编译再 gdb；core 文件要开启 ulimit -c unlimited；C++ 模板、内联、RAII 会让调用栈看起来绕，多用 bt full 和 info registers 辅助判断。练几次，比读十页文档管用。
