ltrace 不能直接跟踪 C++ 成员函数调用，因其仅拦截动态链接符号（如全局函数、extern "C" 函数），而成员函数通常被内联或以未导出的 mangled 名存在，不经过 PLT，故不可见。
ltrace 能否跟踪 C++ 成员函数调用？
不能直接跟踪。ltrace 只能拦截动态链接的符号调用，而 C++ 成员函数（尤其是非虚函数）在编译后通常被内联或以 _ZN 开头的 mangled 名称存在，且不经过 PLT —— 它们不走动态链接器的符号解析路径。ltrace 对这类调用完全不可见。
真正能被 ltrace 捕获的，仅限于：显式链接的共享库中导出的 全局函数、static extern "C" 函数、以及 虚函数表间接调用之外的 dlsym / dlopen 手动调用。
- 确认目标函数是否在
libxxx.so中导出：nm -D /path/to/libxxx.so | grep your_func_name - 若看到的是
U（undefined）或无输出，说明该函数未导出，ltrace无法捕获 - C++ 类方法想被跟踪，必须显式声明为
extern "C"并导出（如加__attribute__((visibility("default")))）
如何让 ltrace 正确加载并显示 C++ 程序调用的动态库函数
关键不是改代码，而是确保符号可见性 + 链接方式正确。默认 g++ 编译的可执行文件使用 -fPIE -pie（现代发行版常见），这会导致 ltrace 因地址随机化和 PLT 重定位问题漏掉部分调用。
- 编译时加
-Wl,-z,now -Wl,-z,relro不影响ltrace，但加-no-pie更稳妥（尤其调试期） - 确保目标库已安装且
LD_LIBRARY_PATH包含其路径，否则ltrace启动即失败，报错类似：ltrace: error while loading shared libraries: libxxx.so: cannot open shared object file - 运行命令示例：
ltrace -e "pthread_*@libpthread.so.*" -e "curl_*@libcurl.so.*" ./myapp—— 注意@后指定库名，避免匹配到同名函数的不同实现
为什么 ltrace 输出里看不到 std::string::c_str() 或 std::vector::push_back？
因为这些是模板实例化函数，属于标准库静态内联或通过 libstdc++.so 内部调用，但它们的符号默认不导出（visibility=hidden），且多数被 GCC 内联展开。即使没内联，ltrace 也只显示类似 std::basic_string<char>::c_str() 的 mangled 名，可读性差，还容易因优化被裁剪。
立即学习“C++免费学习笔记（深入）”；
- 想看 STL 行为，用
gdb断点更可靠：b std::string::c_str（需有 debuginfo） -
ltrace -S可同时显示系统调用，但对 C++ 成员函数依然无效 - 若坚持用
ltrace，可临时重新编译 libstdc++ 加-fvisibility=default，但极不推荐——破坏 ABI，仅限研究
常见错误现象与绕过技巧
最常遇到的是“明明调用了 libcurl，ltrace 却一行输出都没有”——这往往不是工具失效，而是动态链接链路断了。
- 检查是否用了
static链接：ldd ./myapp输出不含libcurl.so，则ltrace无从下手 - 程序 fork 后子进程调用库函数？默认
ltrace不跟踪子进程，加-f参数启用递归跟踪 - 函数调用发生在
main之前（如全局对象构造）？ltrace从main入口开始监控，这类调用不可见 - 替代方案：用
LD_DEBUG=libs,symbols看动态链接过程，或perf trace -e 'dynamic:*捕获更底层的符号事件（需 kernel 支持）
真正难的不是让 ltrace 显示几行日志，而是判断哪些调用它本就不可能看见——mangled 名、内联、静态链接、构造器早于 main，这些点一旦忽略，排查方向就全偏了。
