用户态程序无法直接读取rip/eip，因其受cpu和操作系统保护；唯一可靠方式是用call+pop等汇编惯用法间接获取下一条指令地址，__builtin_return_address(0)返回调用返回地址而非当前指令地址。
为什么不能直接读 RIP/EIP 寄存器
指令指针寄存器（x86-64 是 RIP，x86 是 EIP）在用户态程序中无法通过普通汇编指令（如 mov rax, rip）直接读取——它不是通用寄存器，没有对应的可读取别名。尝试用内联汇编硬读会触发非法指令或编译失败。所有“获取当前 RIP”的方法，本质都是**让 CPU 在执行某条指令时，把该指令的地址作为“下一条将要执行的地址”隐式压入栈或计算出来**。
用内联汇编 + call 指令获取当前 RIP（最可靠）
利用 call 指令会把返回地址（即下一条指令地址）压入栈的特性，跳转到一个标签并立即从栈中弹出该地址。这是 ABI 稳定、无副作用、跨编译器（GCC/Clang/MSVC）都支持的方式：
uintptr_t get_rip() {
uintptr_t rip;
#ifdef __x86_64__
__asm__ volatile (
"call 1f\n\t"
"1: pop %0"
: "=r"(rip)
:
: "rax"
);
#elif defined(__i386__)
__asm__ volatile (
"call 1f\n\t"
"1: pop %0"
: "=r"(rip)
:
: "eax"
);
#endif
return rip;
}
- 必须用
volatile，防止编译器优化掉这段内联汇编 - 输出约束
"=r"(rip)让编译器自由选寄存器，避免硬编码破坏调用约定 -
"rax"或"eax"要声明为 clobber，因为pop会修改它 - 返回值是当前函数中该
call指令**下一条指令**的地址，即逻辑上的“当前执行点”，误差恒为 1 条指令长度（通常可接受）
用 __builtin_return_address(0) 可能不准
__builtin_return_address(0) 返回的是当前函数的**返回地址**，也就是调用者 push 进来的地址。它不等于当前 RIP，尤其在以下情况偏差明显：
- 函数被内联（
inline或编译器自动内联）→ 返回地址指向调用点，而非本函数内部位置 - 使用了尾调用优化（tail call）→ 返回地址可能被覆盖或重定向
- 函数开头有 prologue（如保存
rbp、分配栈帧）→__builtin_return_address(0)指向调用点，而你真正想定位的是此刻正在执行的那行代码
所以它适合调试调用链，不适合精确获取当前指令地址。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
Windows 上用 RtlCaptureContext 的陷阱
Windows SDK 提供 RtlCaptureContext，但它捕获的是完整上下文（包括所有寄存器），且：RtlCaptureContext 不保证 Context.Rip 是“当前执行点”——它可能滞后于实际执行位置，尤其在异步信号（如 SEH）、JIT 或反调试场景下不可靠；它需要链接 ntdll.lib，且在 UWP 或某些沙箱环境被禁用；返回的 Rip 值是进入该函数时的快照，若函数内有分支或延迟，和你想取的那行代码对不上。
除非你在写驱动或底层 hook 工具，否则没必要绕这么大圈子。
真正难的不是“怎么拿到一个数字”，而是确认这个数字对应哪一行源码、是否被优化偏移、是否在异常上下文中仍有效——这些细节比语法本身更消耗调试时间。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
