根本原因是内核函数如tcp_v4_connect、do_sys_open默认未导出fentry/kprobe符号，且可能被内联或未启用config_kprobes/config_ftrace_with_regs；需先验证符号存在性、内核配置及debugfs挂载状态，再选择fentry（低开销）或kprobe（通用）方式attach。
为什么直接用 bpf_probe 无法追踪内核函数？
因为内核函数（如 tcp_v4_connect、do_sys_open）默认不带 fentry 或 kprobe 符号导出，libbpf 的 bpf_program__attach_kprobe 会失败，报错类似：failed to attach kprobe: Operation not permitted 或 No such file or directory。根本原因是：你试图 attach 的函数名在 /sys/kernel/debug/tracing/events/kprobes/ 下不存在，或符号未被内核配置为可探测。
解决路径只有两条：用 kprobe 动态插桩（需符号存在且未被 CONFIG_KPROBES 禁用），或改用 fentry（要求函数有 ftrace 支持且编译时开启 CONFIG_FTRACE_WITH_REGS）。
- 优先查符号是否存在：
cat /proc/kallsyms | grep tcp_v4_connect；若无输出，说明该函数被 inline 或未导出 - 确认内核支持：
zcat /proc/config.gz | grep -E "(KPROBES|FTRACE_WITH_REGS)"（或查/boot/config-$(uname -r)） -
fentry比kprobe开销低、更稳定，但仅适用于非 inline 函数；kprobe更通用，但可能因内联失效
如何用 libbpf-go 正确 attach fentry 到 tcp_v4_connect？
不能直接写 SEC("fentry/tcp_v4_connect") 就完事——Go 侧必须显式指定程序类型和 attach target，且 BPF 程序需用 __attribute__((section("fentry"))) 标记（C 部分），Go 侧调用需匹配。
关键实操步骤：
- BPF C 代码里用
SEC("fentry/tcp_v4_connect")，函数签名必须为int func(struct pt_regs *ctx)，不可省略struct pt_regs * - Go 中加载后，对 program 调用
prog.Attach()前，先确保已调用prog.SetProgramType(bpf.ProgramTypeTracing)和prog.SetAttachType(bpf.AttachTraceFEntry) - 若 attach 失败并提示
Invalid argument，大概率是函数名拼错或内核未导出；可用bpftool prog list确认程序是否加载成功，再用bpftool prog dump xlated name your_prog_name查校验 - 注意：不同内核版本函数名可能变化（如
tcp_v4_connect在 5.10+ 是inet_stream_connect的一部分），建议用bpftool btf dump file /sys/kernel/btf/vmlinux format c查实际符号
为什么 Go 用户常在 libbpf-go 中遇到 no such device 错误？
这不是设备问题，而是 libbpf 在尝试 attach 时找不到目标函数的 BTF 信息，或当前内核不支持该 attach 类型。典型触发场景：用 fentry 但内核没启用 BTF，或用 kprobe 但 /sys/kernel/debug/tracing/events/kprobes/ 不可写（权限或 debugfs 未挂载）。
- 检查 debugfs 是否挂载：
mount | grep debugfs；若无，执行sudo mount -t debugfs none /sys/kernel/debug - 确认 BTF 可用：
ls /sys/kernel/btf/vmlinux应存在；若无，需重新编译内核并开启CONFIG_DEBUG_INFO_BTF=y - Go 程序必须以 root 运行，且 cap_sys_admin 已绑定（
sudo setcap cap_sys_admin+ep ./your-program可避免全 root） - libbpf-go v0.4+ 默认启用 BTF 自动重定位，但如果 BPF 对象由 clang + llc 编译（而非 bpftool gen skeleton），可能缺少 .BTF section，导致 attach 失败
如何安全读取 pt_regs 中的参数（比如 sys_open 的文件路径）？
内核函数参数位置依赖 ABI（x86_64 是 rdi, rsi, rdx…），但 eBPF 不能直接访问寄存器值，必须用 bpf_probe_read_kernel 或 bpf_probe_read_kernel_str 安全拷贝，否则 verifier 拒绝加载。
- 对于
sys_openat（推荐替代sys_open），路径参数在rsi（即ctx->rsi），但它是用户空间地址，必须用bpf_probe_read_kernel_str(&buf, sizeof(buf), (void *)ctx->rsi) - 不要用
strcpy或裸指针解引用；verifier 会报invalid mem access - 缓冲区必须是栈上固定大小数组（如
char buf[256]），不能是全局或 heap 分配 - 若读取失败（返回负值），常见原因是地址无效或页未映射，此时应跳过日志，避免 flood ringbuf
SEC("fentry/do_sys_open")，在 5.15 上能跑，在 6.1 上可能因函数被 refactor 成 __do_sys_open 而静默失效。每次换内核，都得重新 grep + bpftool btf dump 确认。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
