__cxa_demangle 不能直接反解当前函数名，因为它仅用于解码已有的 Itanium ABI 修饰名（如 _Z3fooi），而 C++ 标准不提供运行时获取函数修饰名的接口；__func__ 和 __PRETTY_FUNCTION__ 返回的是可读名或调试字符串，并非标准修饰名，需借助 dladdr + __builtin_return_address 等机制从符号表中提取，且受内联、优化、可见性等限制。
为什么 __cxa_demangle 不能直接反解当前函数名
因为 C++ 没有标准接口在运行时获取“当前函数的修饰名”，__cxa_demangle 只负责反解（demangle）已有的修饰名字符串，它不生成也不提供获取途径。你得先拿到那个以 _Z 或 _ZN 开头的原始字符串，才能喂给它。而 __FUNCTION__、__func__ 给的是可读名（如 "foo），不是修饰名；__PRETTY_FUNCTION__ 虽然含模板信息，但仍是人可读格式，不是 ABI 标准的 mangled 字符串。
用 __builtin_return_address + dladdr 拿到符号地址再查名
这是 Linux/glibc 下最可行的实操路径：靠返回地址定位函数入口，再通过动态链接器查符号表。注意它查到的是“符号名”（symbol name），在未开启 -fvisibility=hidden 且未被 strip 的情况下，这个符号名通常就是修饰名。
-
dladdr需要链接-ldl - 必须传入函数的**代码地址**，
__builtin_return_address(0)是调用点地址，可能落在函数内联展开后的位置，不够稳；更可靠的是在函数开头取&some_local_label或用__builtin_frame_address(0)辅助对齐（但仍有风险） - 实际拿到的
dli_sname可能为nullptr（例如 inlined 函数、static 函数、或编译器优化丢弃了符号）
#include <dlfcn.h>
#include <iostream>
void test_func(int x) {
Dl_info info;
if (dladdr(__builtin_return_address(0), &info) && info.dli_sname) {
std::cout <h3>手动 mangle 的路基本走不通</h3>
<p>不要尝试自己拼接修饰名——Itanium C++ ABI 的 mangling 规则极其复杂，涉及嵌套、模板参数折叠、decltype 推导、lambda 编号等，连 <code>libiberty</code> 的 <code>cplus_demangle</code> 都只做反解，不提供正向生成接口。GCC/Clang 内部用的是专有逻辑，未暴露 API。即使你用 <code>abi::__cxa_demangle</code> 的逆过程，也缺乏稳定输入（比如无法可靠获取模板实参类型在 ABI 中的编码序列）。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<ul>
<li>没有标准库函数叫 <code>__cxa_mangle</code> 或类似名字</li>
<li>
<code>typeid(T).name()</code> 返回的是实现定义的字符串，GCC 返回修饰名，MSVC 返回可读名，Clang 行为又不同，不可移植</li>
<li>宏如 <code>__FUNCDNAME__</code>（MSVC）或 <code>__PRETTY_FUNCTION__</code>（GCC/Clang）都不是修饰名，只是调试辅助字符串</li>
</ul>
<h3>真正能落地的组合方案：编译期 + 运行期协同</h3>
<p>如果目标是日志、调试或 profiling 场景中“尽可能拿到修饰名”，唯一稳健做法是：编译期生成、运行期引用。利用模板和 constexpr，在函数定义处把修饰名固化下来。</p>
<ul>
<li>GCC 提供 <code>__PRETTY_FUNCTION__</code> 在模板函数中会展开完整签名，配合字符串字面量截取可逼近修饰名（不完全等价，但足够用于区分重载）</li>
<li>更彻底的做法：用 build script（如 CMake + <code>nm -C</code> 或 <code>readelf --symbols</code>）在构建后扫描目标文件，提取所有函数的修饰名，生成头文件映射表</li>
<li>运行时通过函数指针查表，避免 <code>dladdr</code> 的不确定性</li>
</ul>
<p>ABI 反混淆本身不难，难的是“获取原始修饰名”这个前提——它不在语言层面，而在工具链与运行环境的交界处。多数人卡住的地方，其实是误以为存在一个“一键获取”的 C++ 标准接口。</p></iostream></dlfcn.h>
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
