不推荐直接用libbpf c++封装，因其纯c设计导致raii失效、裸指针易悬空、错误码难映射异常；加载失败需检查btf、字节码版本、elf结构及权限；tracepoint挂载须严格命名、确保已加载、禁用无效flags；编译需正确链接顺序与头文件路径。
libbpf C++ 封装不推荐直接用
libbpf 是纯 C 库，没有官方 C++ 接口。强行用 extern "C" 包一层函数调用看似可行，但会立刻撞上生命周期、内存管理、错误传播这三堵墙。比如 bpf_object__open() 返回的 struct bpf_object* 必须手动 bpf_object__close()，C++ RAII 机制在这里完全失效，漏掉一次就内存泄漏。
常见错误现象：Segmentation fault 出现在程序退出前，或 bpf_link__destroy() 调用后仍访问 link 句柄——因为 C++ 对象析构顺序不可控，而 libbpf 内部结构体之间有隐式依赖。
- 别自己写
unique_ptr<struct bpf_object decltype></struct>：libbpf 的销毁函数不是无状态的，有些需先 detach，有些要等加载完成才能 close - 别在类成员里存裸指针（如
struct bpf_program*）：它可能随bpf_object销毁而失效，且 libbpf 不保证指针长期有效 - 错误码全靠返回负值（如
-EINVAL），C++ 异常无法自动映射；直接 throw 会绕过 libbpf 自己的 cleanup 逻辑
bpf_object 加载失败的典型原因和检查点
bpf_object__load() 返回 NULL 或负值是最常见的卡点，但错误信息藏得深。libbpf 默认不打印日志，必须显式启用。
- 确保 BTF 信息可用：用
bpftool btf dump file /sys/kernel/btf/vmlinux format c验证内核 BTF 是否就位；否则bpf_object__load()在验证阶段静默失败 - 检查 eBPF 字节码版本：Clang 编译时加
-target bpf -mcpu=v3（v3 支持大部分现代 helper），旧版本（如 v1）在 5.15+ 内核上大概率被拒 - 路径传错：传给
bpf_object__open_file()的是 ELF 路径，不是源码路径；且该文件必须含 .text + .rodata + .maps 等 section，objcopy 后丢失 section 会导致加载失败 - 权限问题：非 root 用户运行时，
bpf_prog_load()会因EPERM失败；临时方案是sudo sysctl kernel.unprivileged_bpf_disabled=0（仅开发环境）
attach 到 tracepoint 的实际操作要点
用 bpf_program__attach_tracepoint() 挂到 syscalls/sys_enter_openat 这类 tracepoint 时，名字拼写、命名空间、参数访问全是坑。
- tracepoint 名必须严格匹配：格式是
"category:event"，中间是英文冒号，不能是下划线或斜杠；"syscalls:sys_enter_openat"对，"syscalls/sys_enter_openat"错 - struct pt_regs *ctx 参数位置固定：eBPF 程序入口函数第一个参数必须是
struct pt_regs *，且只能通过bpf_probe_read_kernel()或bpf_probe_read_kernel_str()读取寄存器内容，不能直接解引用 - attach 前必须确保 program 已 load：
bpf_program__attach_tracepoint()不做 load 检查，若 program 还没 load，返回的struct bpf_link*是无效指针，后续bpf_link__destroy()会 crash - tracepoint attach 不支持 attach_flags：别试图传
BPF_F_ALLOW_MULTI，它只对 kprobe/kretprobe 有效，对 tracepoint 无效且会被忽略
libbpf + C++ 项目编译链接关键配置
链接时出 undefined reference to `bpf_object__open_file' 不是因为没装 libbpf，而是符号可见性或链接顺序不对。
- pkg-config 必须用
libbpf，不是libbpf-devel或libbpf-static：后者是 rpm/deb 包名，pkg-config 文件名始终是libbpf - C++ 编译器必须加
-lbpf且放在源文件之后：如g++ main.cpp -o prog $(pkg-config --libs libbpf)；顺序颠倒会导致链接器忽略库中符号 - 头文件路径：libbpf 头文件通常在
/usr/include/bpf/，但某些发行版（如 Ubuntu 22.04）把它打进了linux-libc-dev，需确认#include <bpf></bpf>能否通过预处理 - 避免静态链接 libbpf：虽然
pkg-config --static --libs libbpf可用，但会把 libz、libelf 等间接依赖全拉进来，容易和系统动态库冲突；优先用动态链接
最麻烦的其实是调试信息缺失——libbpf 报错只给 errno，不告诉你哪行代码触发了哪个 verifier 拒绝。真要定位，得开 LIBBPF_DEBUG=1 环境变量，再结合 bpftool prog dump xlated name xxx 看生成的指令流。这点没人提，但几乎每个人都会卡住半小时以上。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
