It will soon be part of bpf_helpers.h, but meanwhile just copy/paste it into your code. See https://patchwork.kernel.org/project/netdevbpf/patch/20210317200510.1354627-2-andrii@... >

Yes, correct. Yes, you can, if you have vmlinux image with DWARF information in it. You can use pahole tool like this to add .BTF section to vmlinux image: pahole -J <path-to-vmlinux-image> You most p

#bcc

/sys/kernel/btf/vmlinux appeared in 5.4 kernel (upstream version). If you see it on 4.18, that means someone backported the changes. But for BPF CO-RE (which I assume is what you are referring to) to

#bcc

-- Andrii <mayfieldtristan@...> wrote: vmlinux usually refers to kernel image binary. /sys/kernel/btf/vmlinux is not that, it's only the BTF data. So CO-RE needs kernel BTF, not necessarily vmli

As far as CO-RE BPF program compilation goes, there shouldn't be much difference between the latest kernel vs some older one. In case of libbpf-tools, some of the tools might be using some features th

It's expected right now. BTF started out as purely debug information, but got elevated into pretty much a mandatory thing for modern BPF applications. We've talked about making .BTF emitted without -g

[...] Ok, this is a very different issue than the kernel missing BTF. libbpf is complaining that your opensnoop.bpf.o itself is missing BTF. And right, BTF is required to parse map definitions properl

Check example [0] for how to set custom logging callback and print all libbpf logs (including those at DEBUG level of verbosity). [0] https://github.com/iovisor/bcc/blob/master/libbpf-tools/runqslower

<mayfieldtristan@...> wrote: Which version of libbpf are you seeing this on? We've had bugs in libbpf where we'd attempt to load kernel BTF unnecessarily, but I believe we've fixed all those iss

[...] I don't see anything needing kernel BTF in there, so if libbpf still fails on not being able to load kernel BTF, that might be a bug in libbpf. Can you please double-check this with the latest r

Your BPF code must be relying on CO-RE. I can check if you can show me your BPF source code. The pinning and map definition itself doesn't rely on CO-RE and thus doesn't need kernel BTF.

It doesn't require kernel BTF for that. Only BPF program's BTF generated by Clang. So you'll need something like Clang 10 (or maybe Clang 9 will do as well), but no requirements for kernel BTF. >

Libbpf supports declarative pinning of maps, that's how you easily get "map re-use" from BPF side. See [0] for example. But there is also bpf_map__pin() and bpf_map__reuse_fd() API on user-space side

No perf buffer is just fine to pass data from the BPF program in the kernel to the user-space part for post-processing. It's hard to give you any definitive answer, it all depends. But think about thi

I don't think golang can interrupt thread while it's being executed in the kernel. So from the golang perspective I wouldn't worry, the kernel will execute both kprobe and corresponding kretprobe befo

#bcc #pragma

If you have the luxury of using Linux kernel 5.8 or newer, you can try a new BPF ring buffer map, that provides MPSC queue (so you can queue from multiple CPUs simultaneously, while BPF perf buffer al

You can't do it reliably with kretprobe. kretprobe is executed right before the function is exiting, by that time all the registers that contained input parameters could have been used for something e

#bcc #pragma

You should use __sync_fetch_and_add() for both cases, and then yes, you won't lose any update. You probably would want __sync_add_and_fetch() to get the counter after update, but that's not supported

Ok, that I can help with, then. What's the kernel version? Where I can find repro? Steps, etc. Basically, a bit more context would help, as I wasn't part of initial discussion.

<brouer@...> wrote: This is newer Clang recording that function is global, not static. libbpf is sanitizing BTF to remove this flag, if kernel doesn't support this. But given this is re-impleme