Post #385

糊出来了一个 bpf-helper-tracer，也算是基本达到自己的预期，希望以后可以通过观测的方式去调查一些 bpf 程序的 bug，而不是反复读代码、在大脑中推演程序运行，这太唯心主义了！ 虽然目前还只能支持 tc-bpf，但是用法是这样的： ./bpf-helpers-tracer --prog-id 822 'tcp[tcpflags] = tcp-syn' - 指定 bpf 程序的 id - 指定 pcap-filter 规则 输出的每一行是满足规则的 skb 命中的 bpf helper、参数、调用 helper 的 bpf prog 名字和偏移、源码，如 ffff9b3804302ee8 bpf_prog_f6ce4980046b654c_tail_ipv4_ct_egress+410 bpf_skb_load_bytes(skb=0xffff9b3804302ee8, offset=34, to=18446647214680849296, len=4, __ur_1=18446633268455445784) // ret = ctx_load_bytes(ctx, l4_off, ports, 4); 这样不仅可以间接得知 tailcall 的情况，还能更细粒度观测程序分支走向，和 bpf map 里的 kv，可以用来排查控制平面的 bug. 目前最不直观的还是 map kv 的输出，是固定长度的 hex，其实就算是后处理也能解析出 map name 和具体的结构体字段，但我实在太懒了。 还有就是返回值，不能加 kretprobe 因为会复写 *(cfa-8)。 还有就是现在纯粹是糊上去的，实现和代码结构都不行，前后处理的性能都很差。 还有一些多核上的并行的 bug。。。