I am working on an application which utilizes eBPF and am interested in targeting OpenWRT. I found that OpenWRT's kernel does not ship with BTF type information which breaks BPF CO-RE. BPF CO-RE requires this information to be provided by the kernel to apply relocations against the kernel headers the application was compiled against. Without this enabled, it requires recompiling against any kernel you want to ship against. Most major distributions ship with this enabled now as eBPF applications are becoming more common.

I was able to recompile OpenWrt kernel with CONFIG_DEBUG_INFO_BTF=y and confirmed this resolves the issue with eBPF applications.

I fully realize there are some tradeoffs to consider to enabling this, from what I can understand:

  • The kernel size increases, in my testing I found it increased vmlinuz by 1.3mb
  • Build directory storage consumption increases
  • Build time increases -

I have no idea if I'm out to lunch asking for this or not. For my own purposes I can compile it with it enabled, but I'm asking if this is something that can be considered for being enabled in official builds.

The increase in size would likely be the main hindrance.

depends on the platform, I guess, 1.3mb on x86, RPi, etc, wouldn't be a big issue ...


By default kernel is built withot debuginfo. No matter format you select. You build debug kernel if you need to debug it.

1 Like

The use case is not to enable a person to debug the kernel, but to provide runtime compatibility for eBPF applications. These applications can be used for debugging purposes, but they can also be used for monitoring and transforming traffic in profound ways.

Not the point I was trying to make, but OK..

1 Like

Yes, automated debugging, but has to be in ram unlike for gdb.