先说几个核心判断：在C++里想“直接拿到调用者地址”，这事儿比看起来要棘手得多。很多人第一反应就是__builtin_return_address，但这里有个关键误区——它返回的并不是调用者函数的入口地址，而是调用完成后要跳回去的返回地址。这俩东西，在一般情况下，根本不是一回事。
更现实的问题是，这个内建函数高度依赖编译器和ABI（应用程序二进制接口），而且一旦开启优化，结果就很容易变得不可靠，甚至直接失效。
为什么 __builtin_return_address(0) 不等于“调用者函数地址”
让我们先拆解一下：这个函数返回的，实际上是当前函数栈帧里的那个“返回地址”——也就是call指令执行完后，下一条要执行的指令所在的位置。而调用者函数的起始地址呢？那是符号表里的_start或者别的什么入口，两者只有在极简、无优化、无内联、无尾调用的情况下，才可能凑巧重合。
具体来说，有两个常见的“坑”：
- 如果调用者被内联了（
inline关键字或者-O2默认行为），__builtin_return_address(0)指向的就不再是它，而是“再上一级”函数的返回点，甚至可能直接越界。 - 如果启用了尾调用优化（比如
-foptimize-sibling-calls），返回地址可能被复写，结果就彻底不可靠了。 - 另外，在Windows的MSVC编译器下，这个内建函数压根不存在。GCC和Clang的行为也不完全一致——比如
__builtin_return_address(1)在某些栈布局下，会直接读取到无效内存。
如何相对可靠地拿到调用者所在的函数名（非地址）
说到实际需求，大部分场景下，我们真正想知道的其实是“谁调用了我的函数”，而不是一个裸指针地址。这时候，应该转向符号化解析加上编译器辅助的手段。
- 用
__PRETTY_FUNCTION__或__func__可以拿到当前函数名——但注意，这是被调用者自己的名字，不是调用者。 - 配合
backtrace()加backtrace_symbols()（需要链接-lexecinfo或-lbfd）可以获取整个调用栈的符号信息。但代价是开销大，不适合在热路径（hot path）上使用。 - 更轻量、也更推荐的做法是：在关键的调用点，手动传入
__func__或__FILE__ ":" STRINGIFY(__LINE__)。比如这样：
void log_call(const char* caller) {
printf("called from %s\n", caller);
}
// 调用方写成：
log_call(__func__); // 这才是真正的调用者函数名
这才是最直接、也最可靠的做法。
用 __builtin_return_address 的唯一合理场景
坦白说，这个函数最合适的舞台，仅限于底层设施开发——比如自定义的panic handler、栈遍历器、或者协程切换前保存上下文这类场景。而且，使用时必须满足几个硬性条件：
- 编译时禁用优化：
-O0，并加上-fno-omit-frame-pointer（x86_64架构下必须） - 确认目标平台支持这个内建函数（Clang/GCC版本≥4.5，ARM64架构下需要注意：
__builtin_return_address(0)可能返回的是lr寄存器值，而不是内存中保存的返回地址） - 永远不要直接对返回地址做算术运算或者跳转——
reinterpret_cast这样的写法，是明确的未定义行为。 - 如果需要解析符号，必须配合
dladdr()，而且要注意：对于内联函数，dli_sname字段会是空的。
归根结底，当你想定位调用链时，__builtin_return_address是一个相当脆弱的原语。它暴露的是机器层面的细节，而不是编程模型中的“函数”。调试信息、编译器插桩（-finstrument-functions），或者更现代的方式如libunwind，才是更可控、更值得依赖的选择。别为了“看起来好像拿到了调用者”，而去绕开工具链本身的设计意图。
