Instead of using cgo we call the syscall for BPF directly from go. The
API hasn't changed, however, and we also closely follow the
C-implementation as given in bpf(2).
Not sure if this pure go variant is beneficial. Manual maintenance of
all constants and structs upon changes of the BPF API would be necessary
and cumbersome.
We would at least need to complement this with auto-generation of
constants and fields from /usr/include/linux/bpf.h.
main.go:
- reading /proc
- iteration over entries in NNN/maps
- filter glob-search for "*python3*" in pathname
- find symbol and its offset in pathnanme
- calculate offset in memory
- add pid and offset to map
TODO: encapsulating this into a module
ebpf.go:
- added type MapFD int, changing all function on a FD to methods
This allows us to enrich the data type going forward
- added bpf_update_elem() from the manpage ebpf2.
.updateElement() is the verbatim wrapper to it.
- added .Add/.Change/.Set methods, which call .updateElement
with specific flags
TODO: re-implement ebpf.go with pure go, using direct syscalls.
