On 11/26, John Fastabend wrote: > Stanislav Fomichev wrote: > > If vmlinux BTF generation fails, but CONFIG_DEBUG_INFO_BTF is set, > > .BTF section of vmlinux is empty and kernel will prohibit > > BPF loading and return "in-kernel BTF is malformed". > > > > --dump-section argument to binutils' objcopy was added in version 2.25. > > When using pre-2.25 binutils, BTF generation silently fails. Convert > > to --only-section which is present on pre-2.25 binutils. > > hmm I think we should fail hard if a feature explicitly asked for > in the .config is not able to be built due to tooling. Otherwise > users may later try to use a feature that can only be supported by > BTF and that will have to fail at runtime. The runtime failure > seems more likely to surprise users compared to the inconvience > of having a compile time error. I view this similar to how having > old ssl libs fails the build with the various signing options are > set. I agree. This is what actually happened to me. At some point all my selftests started to fail. > Can we print a useful help message instead so users can disable > CONFIG_DEBUG_INFO_BTF or update binutils? I'm not sure objcopy returns with error if it fails to execute the command. I guess we can query the size of .BTF section in vmlinux and print an error if it's empty. Another thing we can do is to add a special 'data_size == 0' to btf_parse_vmlinux. That way, at least, kernel can fall-back to pre-BTF world instead of assuming that BTF is malformed (it's not malformed, it's just not there). But that's, again, a surprise at runtime. Checking at build time seems like a better option.
