单步定位条件分支走向的关键是结合汇编级观察与条件表达式求值；next/step 按源码行执行，会跳过 cmp/jcc 等实际跳转指令，需用 stepi + info registers rip 查看 rip 变化，或用 until 跳至分支出口，辅以条件断点快速确认路径。
单步定位条件分支走向，关键不是靠 next 或 step 盲走，而是结合汇编级观察 + 条件表达式求值，否则容易跳过真实跳转点。
为什么 next 和 step 在 if/else 里常失效
源码中的 if (x > 0) 编译后往往被优化成一条比较指令（如 cmp）加一条条件跳转（如 je、jg），而 next 会直接执行完整个语句块（包括 else 分支），step 也只停在下一行源码——根本看不到 CPU 实际跳去了哪。
- 现象：光用
next，从if行直接跳到if块末尾或else块末尾，中间跳转逻辑“消失”了 - 原因：GDB 默认按源码行调试，但分支决策发生在汇编指令级
- 解决思路：切到汇编视图，单步执行机器指令，看
rip（或pc）怎么跳
用 stepi + info registers rip 看清真实跳转
进入汇编单步模式，每条指令都可控，跳转目标一目了然：
- 先用
layout asm或disassemble查看当前函数的汇编（重点关注cmp、test、je、jne、jg等指令） - 在
cmp后用stepi执行一条指令，再立刻执行info registers rip，观察rip是否跳到了else块对应的地址 - 若跳了，说明条件为假；没跳，说明条件为真且执行了
if块内第一条指令 - 注意：
stepi不依赖 debug 信息，适合无符号 stripped 二进制，但不会自动显示源码行号
用 until 快速跳过循环体，直抵分支出口
当条件分支藏在 for/while 循环内部，且你想确认某次迭代中走的是 if 还是 else，until 比反复 next 更可靠：
-
until本质是“运行到当前作用域下一行不回退的位置”，对循环末尾或if块结尾特别有效 - 例如：光标停在
if (flag) { ... }的{行，输入until，GDB 会运行完整个if块（含可能的else），停在}后第一行 - 配合
print flag或print $rax（看上次比较结果寄存器），就能反推走了哪条路 - 慎用：如果
if块里有函数调用或死循环，until会卡住，此时必须切回stepi
条件断点 + print 是最省力的静态确认法
如果你只关心“某次特定条件下走哪个分支”，没必要单步——直接在两个分支入口设条件断点：
-
break file.c:25 if x > 0（if块第一行） break file.c:28 if x （<code>else块第一行）- 运行
continue，看停在哪一个断点，就说明条件判断结果是什么 - 优势：不依赖是否优化、是否有 debug 信息；劣势：无法看到中间寄存器状态或未定义行为触发点
真正难的不是“怎么停”，而是停住之后看不懂汇编跳转逻辑——尤其当编译器做了跳转表（jump table）、内联展开或 tail-call 优化时，rip 的变化和源码行号几乎完全脱钩。这时候得靠 disassemble /m 对齐源码与指令，再逐条 stepi 验证。
