Post #69

我有个不成熟的暴论, libbpf 走的 CO-RE 的路线是错误的方向, 至少对 uprobe / userspace tracing 来说. 通用 userspace dynamic tracing 有以下几个条件: 1. 用户指定 binary 2. 用户指定 offset 3. 用户指定 hook trigger 时的内存操作 而第三点就是 libbpf 的阿基里斯脚踝, compile once 出来的 bpf 机器码难以根据用户需求调整; 有一些办法可以动态, 比如 BPF_PROG_ARRAY 类型的 bpf map 可以动态注册函数动态调用, 但是注册的函数也只能现场根据用户 trace 需求编译成 bpf 程序, 难以做到 CO-RE. 这一点上 bcc 和 gobpf 都是更动态的做法, 现场编译 bcc c code, 其实有更大的灵活性. 题外话, 我以后都打算使用 gobpf 了, 因为 python 解析 dwarf 性能太菜了, 我考察了好几个方案都很失望, cython 或者 ctypes 调用 libdwarf.so 的方案都要现场编译, 那还不如直接 go 呢.