用bpftrace验证Go函数入口需先用nm确认符号存在，否则需加-go:noinline及-go:build -gcflags="all=-N -l"；uprobe须用绝对地址，参数读取需适配Go寄存器/栈约定。
用 bpftrace 快速验证函数入口是否可追踪
Go 程序的函数符号默认不带调试信息，bpftrace 直接按函数名挂载往往失败。先确认目标函数是否在二进制中暴露：运行 nm -C your_binary | grep YourFuncName。若无输出，说明该函数被内联、未导出或编译时去除了符号——此时 uprobe 无法定位。
常见误区是以为加了 //go:noinline 就够了，其实还必须配合 go build -gcflags="all=-N -l" 关闭优化，否则函数仍可能被内联或寄存器分配导致栈帧不可靠。
-
-N禁用内联，-l禁用变量内联和死代码消除 - 仅对调试阶段启用，生产环境不要用，性能损耗明显
- Go 1.21+ 默认启用
buildmode=pie，需额外加-buildmode=exe避免地址随机化干扰 uprobe 定位
用 libbpf-go 在代码中挂载 uprobe
硬编码函数偏移容易失效，推荐用 elf.Open() 动态解析符号地址。注意 Go 二进制是静态链接，没有 PLT/GOT，所以只能用 uprobe（不是 uretprobe），且必须指定绝对地址而非符号名。
示例关键步骤：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
elfFile, _ := elf.Open("your_binary")
sym, _ := elfFile.LookupSymbol("main.YourFuncName")
uprobe := &manager.Probe{
UID: "your_func_uprobe",
Section: "uprobe/YourFuncName",
EBPFProgram: prog,
BinaryPath: "your_binary",
Address: sym.Value, // 不是名字，是 runtime 地址
}
- Go 的 symbol value 是相对于 ELF 文件基址的偏移，
libbpf-go会自动加上加载基址 - 若程序已运行，可用
/proc/PID/maps查实际加载地址，再算相对偏移 - 不要用
perf_event_open手动设 uprobe，libbpf-go的UProbe封装已处理 fork/exec 场景
读取 Go 函数参数要绕过栈帧差异
Go 使用“分段栈”和寄存器传参（如前几个参数走 AX/DX），和 C ABI 不同。直接从 ctx->regs->ax 读可能拿到错误值——因为 Go 编译器可能把参数存在其他寄存器，或已溢出到栈上。
更可靠的方式是：在函数开头插入 runtime·nop 占位符，然后用 bpf_probe_read_user 从当前栈指针向下读取局部变量区。但前提是你的函数有足够栈空间且未被优化掉帧指针。
- 加
//go:nobounds和//go:nocheckptr可减少栈操作干扰 - 用
dlv调试时执行disassemble -a YourFuncName，看前几条指令是否含mov到栈或寄存器 - 参数类型是 interface{} 或 slice 时，实际只传 header 结构体（3 字段），需二次
bpf_probe_read_user解引用
为什么 tracepoint:sched:sched_process_exec 捕不到 Go 子进程
Go 的 os/exec 默认用 clone + execve，但部分场景（如小命令）会用 vfork + execve，而 vfork 不触发 sched_process_exec tracepoint。此时应监听 syscalls:sys_enter_execve，它覆盖所有 exec 变体。
-
sys_enter_execve的ctx->args[0]是 filename 地址，需用bpf_probe_read_user_str读字符串 - Go 进程启动快，eBPF 程序加载延迟可能导致错过早期 exec，建议提前 attach 并用
perf_buffer设置 ringbuf 大小 - 容器环境下需挂载
/sys/fs/cgroup并检查unified模式，否则 cgroup filter 可能失效
dlv 和 readelf 确认函数真实布局，比反复改 eBPF 逻辑更省时间。 
