应直接修改cpu返回寄存器：x86-64用set $rax = 值，x86-32用set $eax = 值；需在函数返回前停住，确认架构，跳转伪造返回时注意地址有效性与资源泄漏风险。
函数返回值被丢弃时怎么改
当代码写成 if (func()) {} else {} 这种形式，func 的返回值没存到变量里，set iRet=1 就失效了。这时候得直接改 CPU 寄存器——x86-64 下是 $rax，x86-32 下是 $eax。
操作前先确认当前架构：show architecture；再在函数即将返回前停住（比如用 finish 到函数末尾，或在 ret 指令处断点），然后执行：
set $rax = 0
常见错误现象：改完没生效，多半是断点位置太早（函数还没执行完）、或者寄存器名写错（比如在 64 位程序里用了 $eax）。
- 32 位程序：用
$eax、$edx（大返回值可能分两个寄存器） - 64 位程序：优先看
$rax，结构体等复杂类型可能走内存返回，这时要查调用约定（如 System V ABI） - 修改后必须继续运行（
c或step），否则寄存器变更不会落地
想让函数提前返回某个值怎么办
不是等它自然返回，而是中途“伪造”返回：在函数开头就跳过所有逻辑，直接把值塞进返回寄存器，再跳到函数末尾的 ret 指令。
步骤是：break func → run → 停住后 set $rax = 42 → jump *func+XX（XX 是函数末尾 ret 的偏移，可用 x/10i func 查）。
容易踩的坑：
-
jump目标地址必须是有效的指令地址，不能指向数据或未映射内存，否则proceed会失败并报Cannot execute this command while the target is running - 跳转后栈帧仍是原函数的，但局部变量、
push/pop平衡可能被破坏，只适合简单函数 - 如果函数有 cleanup 逻辑（比如
fclose、free），跳过会导致资源泄漏
用 call 执行函数并观察返回值
call 是唯一能真正触发函数执行并拿到返回值的方式，但它不等于“调试函数内部”，而是模拟一次调用。
例如：call AddToTop(5) 会执行该函数，打印输出，并把返回值存在 $rax 里，同时 GDB 自动显示结果：
$1 = 15
注意点：
- 被调函数不能有副作用敏感操作（比如修改全局状态、发网络请求），否则会影响后续调试流程
- 参数类型必须匹配，C++ 中需加作用域，如
call ns::func(1) - 如果函数内联了，
call可能失败并提示Cannot resolve function ……，此时加-O0 -g重新编译
为什么 print func() 有时不工作
print 在某些场景下会静默失败，不是语法错，而是 GDB 无法安全插入调用桩——特别是函数带 __attribute__((noreturn))、或符号被 strip、或位于共享库中且无调试信息。
此时你会看到：
No symbol "func" in current context.
或更隐蔽的：
$1 = void
解决路径很实际：
- 确认可执行文件带
-g编译，且没被strip - 用
info functions func看符号是否存在 - 换用
call，它对符号解析更宽松；若仍失败，说明函数根本不可调用（比如被优化掉、或在 PLT 中未解析）
寄存器级干预和 call 行为差异很大：前者绕过函数逻辑，后者真实执行——选哪个，取决于你到底想“跳过 bug”还是“验证修复”。
