On 23/01/2024 00:18, Ian Rogers wrote: > Hi, > > if a kernel is compiled with CONFIG_DEBUG_INFO_BTF disabled then the > libbpf fails on perf lock contention with: > ``` > libbpf: failed to find valid kernel BTF > libbpf: Error loading vmlinux BTF: -3 > libbpf: failed to load object 'lock_contention_bpf' > libbpf: failed to load BPF skeleton 'lock_contention_bpf': -3 > Failed to load lock-contention BPF skeleton > lock contention BPF setup failed > ``` > The same error message is seen with BCC's libbpf-tools. I saw these > messages on default Rapberry Pi OS that is derived from Debian (more > context in https://bugzilla.kernel.org/show_bug.cgi?id=218401). > > Given that distributions are shipping perf and libbpf-tools that > assume BTF is enabled, should CONFIG_DEBUG_INFO_BTF be enabled by > default in the kernel? > That would be great, but if I remember one issue with this might be that CONFIG_DEBUG_INFO_BTF depends on DEBUG_INFO (for the DWARF generation that we construct BTF from), so I suspect enabling debug info by default might be an issue. There has been discussion in the past about supporting CONFIG_DEBUG_INFO_BTF in the non CONFIG_DEBUG_INFO case (by temporarily generating DWARF then stripping it or similar). What most distros usually do is strip the DWARF during packaging and create debuginfo packages, but I imagine users who build kernels themselves would want similar support if they were asking for DEBUG_INFO_BTF but not DEBUG_INFO. > Perhaps: > ``` > libbpf: Error loading vmlinux BTF: -3 > ``` > Would be better as (especially if the user is root): > ``` > libbpf: Error loading vmlinux BTF: -3 (was the kernel compiled with > CONFIG_DEBUG_INFO_BTF?) > That would be great; one thing I think would really help users would be to distinguish two cases in error messaging 1. /sys/kernel/btf/vmlinux is not there at all; for that case your above error message is great (-ESRCH case) 2. /sys/kernel/btf/vmlinux is there, but can't be parsed, likely due to it being built with newer BTF; the current libbpf being used to parse it cannot read it (-EINVAL case). For this case something like ("BTF is present, but cannot be read; it may be malformed, or the version of libbpf reading it (%s) may be too old", version). Having solution-oriented messaging for cases like this would really help users I think. Thanks! Alan ``` > > Thanks, > Ian >
