co-re迁移首步失败主因是.bpf.o缺失btf信息，需clang编译时加-g -o2 -target bpf -mcpu=probe，并用llvm-readelf -s验证btf节存在。
为什么 bpf_object__open_file() 打不开你的 .bpf.o？
CO-RE 迁移第一步就卡住，常见原因是：你用 clang 编译出来的 .bpf.o 没带 BTF 信息，或者用了不兼容的后端（比如默认的 -target bpf 不开 -g 就没 BTF）。libbpf 的 bpf_object__open_file() 会静默失败——它不报错，但返回 NULL，errno 也常是 0。
- 必须加
-g（生成 DWARF）+-O2（否则某些结构体成员偏移无法解析） - 推荐显式指定
-target bpf -mcpu=probe，让 clang 自动探测内核支持的 BPF 指令集 - 检查是否真有 BTF：
llvm-readelf -S your.bpf.o | grep BTF，没输出就说明编译漏了 - 别用
bpftool gen skeleton生成的头文件直接替换旧 bootstrap —— 它依赖新 libbpf 的bpf_object__open_mem()流程，老版本调不通
bpf_link 和 bpf_program__attach() 在 CO-RE 下行为不一致？
不是 bug，是设计变化。CO-RE 程序里所有 bpf_program 默认设为 autoattach = true，但 bpf_program__attach() 不再自动处理 tracepoint/tp 类型程序的子系统注册；它只做「加载后 attach」，而不再管「注册事件点」本身。
- tracepoint 程序必须先调
bpf_program__set_attach_target(prog, 0, "syscalls/sys_enter_openat")，再__attach() - kprobe/kretprobe 必须用
bpf_program__set_attach_target(prog, 0, "do_sys_open")，不能只传函数名字符串 - 如果 attach 失败且
errno == EBUSY，大概率是同一符号已被其他程序占用（比如 perf 或另一个 eBPF 实例），CO-RE 不改变内核限制 - 用
bpf_link替代旧式 attach 更稳妥：它支持延迟 attach、可 detach、自带引用计数，且与 CO-RE 的bpf_object__load()流程天然对齐
bootstrap 示例里 bpf_object__load() 报 EINVAL 怎么查？
这个错误在 CO-RE 场景下往往指向 BTF 重定位失败，而不是代码逻辑错。libbpf 会在 load 阶段尝试把程序里的 struct pt_regs *、struct task_struct * 等类型映射到当前运行内核的布局，一碰上字段缺失或大小变动就炸。
- 先跑
libbpf_print_fn注册日志回调，看具体哪行重定位失败（常见于task_struct->comm在 5.10+ 变成柔性数组，旧 BTF 描述不匹配） - 确保编译时用的是目标内核头文件（
-I /lib/modules/$(uname -r)/build/include），不是发行版预装的 generic headers - 避免在 CO-RE 程序里硬编码结构体大小或偏移（比如
offsetof(struct task_struct, pid)），改用bpf_core_read()+BPF_CORE_READ() - 如果 target 内核太老（bpf_object__load() 会退化为非 CO-RE 模式——但此时若程序用了
BPF_CORE_READ()宏，编译期就过不去
从传统 libbpf 迁移到 CO-RE bootstrap，哪些宏必须改？
不是所有旧宏都能无缝替换。最典型的是 bpf_map__lookup_elem() 和 bpf_map__update_elem() 调用链，在 CO-RE 项目中通常要换成带 _with_fd() 后缀的变体，因为 map FD 现在由 bpf_object 统一管理，不再暴露原始指针。
-
bpf_map__fd(map)返回 -1 是正常态（map 尚未加载），别拿它直接传给syscall(SYS_bpf, ...) -
#include "vmlinux.h"必须放在所有其他头文件之前，否则内核类型定义会被用户头文件污染 -
SEC("kprobe/do_sys_open")里的函数名必须和实际符号完全一致（区分大小写、含前导下划线与否），CO-RE 不做模糊匹配 - 不要在
SEC("maps")里声明大数组（如char buf[64K]），CO-RE 的 map size 校验比旧版更严格，超限直接 load 失败
CO-RE 的麻烦不在语法，而在它把“内核差异”从运行时隐式处理，变成了编译期显式契约。一个 BPF_CORE_READ() 写错层级，或者少 include 一个 helpers.h，都可能让程序在某台机器上静默读错字段——这种问题不会报错，只会让你看到一堆零值或乱码。
