Re: Better error message for kernels not compiled with BTF

[Alan Maguire <alan.maguire@oracle.com>]

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
>