bpftrace追踪C++函数需用mangled名（如_Z12myFunctionv），配合c++filt确认签名；编译加-g -fno-omit-frame-pointer避免内联和符号丢失；读C++对象须谨慎处理this指针、SSO、偏移及生命周期。
怎么让 bpftrace 跟进 C++ 程序的函数调用
bpftrace 本身不解析 C++ 符号，它看到的是编译后的 _Z 开头的 mangled 名。直接写 func_name 会找不到——这是最常卡住的地方。
- 用
c++filt反解符号：echo "_Z12myFunctionv" | c++filt确认目标函数真实签名 - 追踪时必须用 mangled 名：
uprobe:/path/to/binary:_Z12myFunctionv - 如果程序是动态链接的，优先查
libxxx.so而非主 binary，用readelf -Ws /path/to/lib | grep myFunction定位所在模块 - 模板实例化函数（如
std::vector<int>::push_back）mangled 名极长，建议先用nm -C或objdump -t导出全量符号再过滤
uprobe 触发不了？检查 C++ 编译和符号可见性
C++ 默认可能 strip 掉调试符号或内联掉小函数，导致 uprobe 找不到入口点。
- 编译时加
-g -fno-omit-frame-pointer，避免关键帧信息丢失 - 禁用 aggressive inlining：
-fno-inline-small-functions或对目标函数加__attribute__((noinline)) - 确认 binary 没被 strip：
file myapp应含 “not stripped”；若已 strip，readelf -S myapp | grep debug查看是否还有 .debug_* 段残留 - 使用
bpftrace -e 'uprobe:/path/to/binary:missing_func { printf("hit\n"); }'测试是否加载成功，不报错但没输出 = 符号根本没找到
如何安全捕获 C++ 对象参数（比如 this 指针、std::string）
bpftrace 在用户态探针里拿不到完整的 C++ 对象布局，只能按内存偏移硬读原始字节，稍有不慎就 segfault 或读错字段。
-
this指针在 x86_64 上通常是arg0，但需确认调用约定（man 7 signal提到 SysV ABI 中 this 是第一个隐式参数） - 读
std::string内容前，先判断是否短字符串优化（SSO）：*(uint8_t*)arg0 & 0x1为 0 表示指针模式，否则数据内嵌在对象前几个字节 - 避免直接
printf("%s", (char*)ptr)—— 若 ptr 为空或越界，bpftrace 会静默失败；改用str(args->ptr)（仅限 kernel 5.15+）或手动限制长度：memcpy(buf, ptr, 64) - 结构体字段偏移要用
offsetof验证，别靠 IDE 提示——不同 STL 版本、编译器、ABI 下std::vector成员顺序可能不同
为什么 trace 结果和实际逻辑对不上？注意 C++ 运行时特性
C++ 的异常传播、RAII 析构、线程局部存储（TLS）会让执行流不连续，bpftrace 看到的只是“快照”，容易误判因果。
立即学习“C++免费学习笔记（深入）”；
- 析构函数调用可能发生在 return 之后很久（比如栈展开时），
uretprobe捕不到，得单独挂uprobe到 dtor mangled 名 - thread_local 变量地址每次 probe 触发都不同，不能缓存其值；需每次用
u64 tid = pid();+ TLS 基址计算（Linux 用__builtin_thread_pointer()不可用，得靠/proc/pid/maps解析） - 异常抛出时，栈帧可能被跳过，导致
uprobe和uretprobe不成对出现；观察errno == 3（ESRCH）可辅助判断目标线程是否已退出 - STL 容器迭代器失效、move 语义导致的指针转移，会让之前读到的地址瞬间变 dangling —— bpftrace 不做空指针检查，读取即 crash
真正难的不是写 bpftrace 脚本，而是把 C++ 的运行时行为映射成稳定可测的内存事实。符号、偏移、生命周期，三者缺一不可，漏一个，trace 就变成猜谜。
