As a Linux distribution I would like to build kernels quickly, without using too much disk space, have debug symbols enabled, but packaged separately as an optional install (due to their large size). Whilst userspace tooling is fairly optimized, it doesn't seem to be the case for kernel builds. And when I try to use the same techniques or methods for the kernel builds, the tooling seems to fall apart. I am curious to know if the below mentioned problems are known, being worked on, or if there is anything I can do to improve things. Most Linux distributions for userspace binaries today build binaries with debug symbols, then strip them by build id into and then run dwz on them to further optimize them. I would like to do the same or similar for kernels, but having little luck so far. Recently it was enabled to use CONFIG_DEBUG_INFO_DWARF5 option for kernel builds, whilst keeping CONFIG_DEBUG_INFO_BTF and CONFIG_DEBUG_INFO_BTF_MODULES=y features on, as pahole has supported parsing DWARVES5 for a while. That's nice. CONFIG_DEBUG_INFO_SPLIT option looks nice, but turning that on breaks CONFIG_DEBUG_INFO_BTF_MODULES as pahole fails to process .dwo files. Also nothing seems to install .dwo files, thus an unstripped/debug build install of modules doesn't install all the .dwo files. But pahole can process .dwp that is a packaging of .dwo produced by dwp utility. But that leads to no joy either, as dwp segfaults on DWARF5 .dwo files and .dwp files are not shipped and can't be locate by like a filepath note / shipped in by build-id directories, as they have to be called $EXE.dwp to be usable. I guess I could create .dwp files temporary to generate pahole BTF information, whilst shipping .dwo files for debugging. If/when dwp is fixed for DWARF5. Separately I've tried detaching and/or optimizing debug symbols using dwz, which fails on kernels as it's not a supported binary type. I wish I could use DWARF5, split dwarve, have a working pahole/BTF, and optimize/pack all the debug symbols for a kernel build and its module, to hopefully reduce the size of kernel debug symbols packages in the distributions. But it seems that all of my attempts are so far futile. Are the above mentioned issues known? Worth fixing? Are they the best strategy or is there something else I can do? -- Regards, Dimitri.
