__cxa_demangle 不能直接反解当前函数名，因为它仅用于解码已有的 Itanium ABI 修饰名（如 _Z3fooi），而 C++ 标准不提供运行时获取函数修饰名的接口；__func__ 和 __PRETTY_FUNCTION__ 返回的是可读名或调试字符串，并非标准修饰名，需借助 dladdr + __builtin_return_address 等机制从符号表中提取，且受内联、优化、可见性等限制。
为什么 __cxa_demangle 不能直接反解当前函数名
因为 C++ 没有标准接口在运行时获取“当前函数的修饰名”，__cxa_demangle 只负责反解（demangle）已有的修饰名字符串，它不生成也不提供获取途径。你得先拿到那个以 _Z 或 _ZN 开头的原始字符串，才能喂给它。而 __FUNCTION__、__func__ 给的是可读名（如 "foo<int>"</int>），不是修饰名；__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 << "Mangled symbol: " << info.dli_sname << "\n";
// 输出类似: _Z9test_funci
}
}
手动 mangle 的路基本走不通
不要尝试自己拼接修饰名——Itanium C++ ABI 的 mangling 规则极其复杂，涉及嵌套、模板参数折叠、decltype 推导、lambda 编号等，连 libiberty 的 cplus_demangle 都只做反解，不提供正向生成接口。GCC/Clang 内部用的是专有逻辑，未暴露 API。即使你用 abi::__cxa_demangle 的逆过程，也缺乏稳定输入（比如无法可靠获取模板实参类型在 ABI 中的编码序列）。
- 没有标准库函数叫
__cxa_mangle或类似名字 -
typeid(T).name()返回的是实现定义的字符串，GCC 返回修饰名，MSVC 返回可读名，Clang 行为又不同，不可移植 - 宏如
__FUNCDNAME__（MSVC）或__PRETTY_FUNCTION__（GCC/Clang）都不是修饰名，只是调试辅助字符串
真正能落地的组合方案：编译期 + 运行期协同
如果目标是日志、调试或 profiling 场景中“尽可能拿到修饰名”，唯一稳健做法是：编译期生成、运行期引用。利用模板和 constexpr，在函数定义处把修饰名固化下来。
立即学习“C++免费学习笔记（深入）”；
- GCC 提供
__PRETTY_FUNCTION__在模板函数中会展开完整签名，配合字符串字面量截取可逼近修饰名（不完全等价，但足够用于区分重载） - 更彻底的做法：用 build script（如 CMake +
nm -C或readelf --symbols）在构建后扫描目标文件，提取所有函数的修饰名，生成头文件映射表 - 运行时通过函数指针查表，避免
dladdr的不确定性
ABI 反混淆本身不难，难的是“获取原始修饰名”这个前提——它不在语言层面，而在工具链与运行环境的交界处。多数人卡住的地方，其实是误以为存在一个“一键获取”的 C++ 标准接口。
