On Wed, 2023-09-13 at 15:26 +0100, Alan Maguire wrote: > > > > When a newer pahole is run on an older kernel, it often knows about BTF > > > > kinds that the kernel does not support, and adds them to the BTF > > > > representation. This is a problem because the BTF generated is then > > > > embedded in the kernel image. When it is later read - possibly by > > > > a different older toolchain or by the kernel directly - it is not usable. > > > > > > > > The scripts/pahole-flags.sh script enumerates the various pahole options > > > > available associated with various versions of pahole, but in the case > > > > of an older kernel is the set of BTF kinds the _kernel_ can handle that > > > > is of more importance. > > > > > > > > Because recent features such as BTF_KIND_ENUM64 are added by default > > > > (and only skipped if --skip_encoding_btf_* is set), BTF will be > > > > created with these newer kinds that the older kernel cannot read. > > > > This can be (and has been) fixed by stable-backporting --skip options, > > > > but this is cumbersome and would have to be done every time a new BTF kind > > > > is introduced. > > > > > > > > So this series attempts to detect the BTF kinds supported by the > > > > kernel/modules so that this can inform BTF encoding for older > > > > kernels. We look for BTF_KIND_MAX - either as an enumerated value > > > > in vmlinux DWARF (patch 1) or as an enumerated value in base vmlinux > > > > BTF (patch 3). Knowing this prior to encoding BTF allows us to specify > > > > skip_encoding options to avoid having BTF with kinds the kernel itself > > > > will not understand. > > > > > > > > The aim is to minimize pain for older stable kernels when new BTF > > > > kinds are introduced. Kind encoding [1] can solve the parsing problem > > > > with BTF, but this approach is intended to ensure generated BTF is > > > > usable when newer pahole runs on older kernels. > > > > > > > > This approach requires BTF kinds to be defined via an enumerated type, > > > > which happened for 5.16 and later. Older kernels than this used #defines > > > > so the approach will only work for 5.16 stable kernels and later currently. > > > > > > > > With this change in hand, adding new BTF kinds becomes a bit simpler, > > > > at least for the user of pahole. All that needs to be done is to add > > > > internal "skip_new_kind" booleans to struct conf_load and set them > > > > in dwarves__set_btf_kind_max() if the detected maximum kind is less > > > > than the kind in question - in other words, if the kernel does not know > > > > about that kind. In that case, we will not use it in encoding. > > > > > > > > The approach was tested on Linux 5.16 as released, i.e. prior to the > > > > backports adding --skip_encoding logic, and the BTF generated did not > > > > contain kinds > BTF_KIND_MAX for the kernel (corresponding to > > > > BTF_KIND_DECL_TAG in that case). Hi Alan, I tested this patch (by tweaking BTF_KIND_MAX value and comparing generated BTF) and it seems to work as intended. Left a few nitpicks. Thanks, Eduard > > > > > > > > Changes since RFC [2]: > > > > - added --skip_autodetect_btf_kind_max to disable kind autodetection > > > > (Jiri, patch 2) > > > > > > > > [1] https://lore.kernel.org/bpf/20230616171728.530116-1-alan.maguire@xxxxxxxxxx/ > > > > [2] https://lore.kernel.org/bpf/20230720201443.224040-1-alan.maguire@xxxxxxxxxx/ > > > > > > > > Alan Maguire (3): > > > > dwarves: auto-detect maximum kind supported by vmlinux > > > > pahole: add --skip_autodetect_btf_kind_max to disable kind autodetect > > > > btf_encoder: learn BTF_KIND_MAX value from base BTF when generating > > > > split BTF > > > > > > > > btf_encoder.c | 37 +++++++++++++++++++++++++++++++++ > > > > btf_encoder.h | 2 ++ > > > > dwarf_loader.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++ > > > > dwarves.h | 3 +++ > > > > man-pages/pahole.1 | 4 ++++ > > > > pahole.c | 10 +++++++++ > > > > 6 files changed, 108 insertions(+) > > > >
