在当前文件某一行设断点用break 行号，需确保已加载带-g编译的可执行文件且源码路径可达；跨文件须显式写break 文件名:行号；用info breakpoints确认状态，避免因优化、路径或符号表缺失导致断点失效。
在当前文件的某一行设置断点
直接用 break 加行号，GDB 就会在当前源文件的对应行开头插入断点。前提是已加载带调试信息的可执行文件（编译时加了 -g），且当前工作目录能定位到源码。
常见错误现象：输入 b 42 后提示 No symbol table is loaded 或 Function not defined —— 这不是语法错，而是没符号表或源码不可见。
- 确保编译命令包含
-g，例如：g++ -g -o demo demo.cpp - 启动 GDB 时最好从源码所在目录运行：
gdb ./demo，避免路径不一致导致找不到源文件 - 如果当前不是目标源文件，GDB 默认在
main所在文件里找行号；想跨文件打，必须显式写全：break demo.cpp:6
在其他文件的某一行设置断点
当项目有多个源文件，且你想在非当前默认文件中设断点，必须带上文件名和冒号。GDB 不会自动推断你在哪个 .cpp 里敲的行号。
使用场景：比如你正在调试 main.cpp，但想在 utils.cpp 的第 15 行暂停，就不能只输 b 15。
- 正确写法是：
break utils.cpp:15或简写为b utils.cpp:15 - 文件名支持相对路径，如
src/network.cpp:88；但不能用通配符或 shell 展开（*.cpp:10无效） - 如果报错
No source file named xxx，说明 GDB 没找到该文件——检查编译时是否用了绝对路径、是否启用了-fdebug-prefix-map等影响路径记录的选项
设置后怎么确认断点生效了
break 命令执行成功只会返回类似 Breakpoint 1 at 0x401132: file demo.cpp, line 6. 的提示，但不保证后续一定能停住。真正要验证，得靠 info breakpoints。
容易被忽略的细节：断点编号（如 Num 列）是会递增的，即使你删掉中间某个断点，新断点编号也不会重排；退出 GDB 后所有断点清空——这和 IDE 里的“保存断点”习惯完全不同。
- 查看全部断点状态：
info breakpoints（缩写i b），注意看Enb列是否为y - 如果
What列显示的是地址（如*0x401132）而非file:line，说明源码信息丢失，断点可能无法按行触发 - 运行程序前务必先
r或run，否则断点只是“存在”，不会被激活
为什么打了断点却没停住
最常被低估的原因是编译优化。哪怕你写了 break main.cpp:20，如果用了 -O2，GDB 可能根本找不到第 20 行对应的机器指令——行号映射失效，断点自动挂载到附近函数入口或干脆静默失败。
性能与兼容性影响：开启 -g 不影响运行时性能，但 -O 和 -g 共存时，调试体验会下降。生产环境调试建议用 -O0 -g 或 -O1 -g 折中。
- 临时验证：编译时去掉优化，例如
g++ -O0 -g demo.cpp -o demo - 检查是否真被优化掉：在断点位置前加
asm volatile("nop");，再试b，能停住就基本确定是优化干扰 - 别依赖
list显示的行号去打——它可能因宏展开、内联而错位；用info sources确认 GDB 实际加载了哪些文件
break 变成“看起来设了，其实没用”。
