gdb的step命令卡顿或跳转异常的直接原因是进入无调试符号的函数或启用激进优化（如-o2/-o3）导致源码与指令映射失败；应改用next、编译时用-g-o0，并在必要时用stepi指令级单步。
直接原因通常是用了 step 进入了未带调试符号的函数，或者编译时没加 -g 但启用了激进优化（如 -O2 或 -O3），导致 GDB 无法准确映射源码与指令，被迫反复查表、回溯、猜测行号。
为什么 step 会卡住或跳得不按预期
当 GDB 遇到没有调试信息的函数（比如系统库、release 编译的第三方库、或漏加 -g 的自己代码），step 会尝试“模拟单步”：它得靠符号表 + 行号信息推断下一行在哪；一旦缺失，就只能退回到指令级，甚至放弃行级控制，表现为卡顿、跳过整块逻辑、或直接跳出函数。
- 典型现象：
Single stepping until exit from function xxx, which has no line number information. -
step在内联函数、宏展开多的代码里也容易失准——因为预处理后实际执行的指令和源码行已不一一对应 - 如果函数被
-O2优化掉（例如被内联、尾调用消除、死代码删除），step可能根本“找不到”那行，转而停在不可预料的位置
用 next 替代 step 控制粒度
next 不进入函数体，只执行当前行（哪怕这行调用了函数），所以它不依赖被调函数是否有调试信息，速度稳定得多。多数调试场景下，你真正关心的是“我这行逻辑有没有走对”，而不是“printf 内部怎么实现”。
- 适合：快速过掉标准库调用、日志打印、配置加载等非核心逻辑
- 注意：
next在循环或条件分支里仍按源码行推进，不会跳过整个循环体 - 若某行确实需要进函数看细节，先确认该函数是否编译进了调试符号（
info functions 函数名能查到才可靠）
编译时必须加 -g，且避免高优化等级混用
没有 -g，GDB 就是盲人摸象；加上 -O2 或更高，等于给盲人蒙上更厚的布——符号还在，但变量被寄存器复用、代码重排、行号错位，step 效率断崖式下跌。
- 开发调试阶段，固定用：
gcc -g -O0（禁用优化）或保守的-O1 - 不要用
-g -O2混搭：看似有符号，实则 GDB 常常无法把$rax的值对应到某个 C 变量名，print出来是<optimized out></optimized> - 验证是否有效：
readelf -S ./a.out | grep debug—— 有输出说明调试段存在；file ./a.out应含with debug_info
真要指令级单步时，用 stepi + display/i $pc
当你确认问题出在汇编层（比如怀疑寄存器被意外修改、栈帧异常），stepi 是唯一可靠选择。它不依赖源码，每次只走一条 CPU 指令，速度恒定。
- 启动前先执行：
display/i $pc，这样每步都会自动显示当前指令，不用反复敲x/i $pc - 配合
info registers看关键寄存器变化，比盯着 C 源码更直接 - 缺点：需懂基本 x86-64/ARM 指令，且无法直接看到高级语言语义（比如不知道哪条
mov对应i++）
最易被忽略的一点：很多人以为只要加了 -g 就万事大吉，其实 -O2 下的调试体验和 -O0 完全是两个世界。别为了省那零点几秒的编译时间，把单步调试拖成分钟级——开关就在编译命令里，改一下就行。
