In kernel-build.eclass, we currently do... ``` # Use the kernel build system to strip, this ensures the modules # are stripped *before* they are signed or compressed. local strip_args if use strip; then strip_args="--strip-unneeded" fi # Modules were already stripped by the kernel build system dostrip -x /lib/modules [...] # Install vmlinux with debuginfo when requested if use debug; then if [[ "${image_path}" != "vmlinux" ]]; then mv "build/vmlinux" "${ED}${kernel_dir}/vmlinux" || die fi dostrip -x "${kernel_dir}/vmlinux" fi ``` This interacts in an interesting way with enabling BTF debug information, because we end up not just having BTF, but also *keeping the DWARF* because we're not stripping vmlinux. Maybe USE=strip should, if USE=-debug, call `strip` on vmlinux but make sure to pass --keep-section=".BTF" (or whatever it is).
Aside: I _think_ we do the right thing for modules right now, but I'll note that when we set INSTALL_MOD_STRIP, we clobber the default '--strip-debug' with our '--strip-unneeded' (https://docs.kernel.org/kbuild/kbuild.html#install-mod-strip). But maybe that's OK.
(In reply to Sam James from comment #1) > Aside: I _think_ we do the right thing for modules right now, but I'll note > that when we set INSTALL_MOD_STRIP, we clobber the default '--strip-debug' > with our '--strip-unneeded' > (https://docs.kernel.org/kbuild/kbuild.html#install-mod-strip). But maybe > that's OK. actually, maybe it's bad, because with USE="strip debug", we kill any debug info (although I think we end up keeping BTF) in /lib/modules, i.e. we don't cater for USE=debug there either. Or maybe we shouldn't worry about that.
(I split my other comments into bug 938958.)
Martin: cc'd you as you may have some input here. The context is "we're likely to enable BTF by default, trying to figure out what it's useful/not useful for USE=debug to do in light of this."
Thanks for Cc'ing me. This is ultimately an issue with the USE flags I think. For the whole system there are multiple FEATURES one might work with including "installsources", "compressdebug", "splitdebug", "nostrip" which have pretty clear meaning and with various combinations one is able to achieve pretty much what one desires (or at least with my limited imagination). The kernel USE flags are much more limited and it is non-intuitive how they should behave in combination. At least I can imagine so much when multiple people would be tasked with describing the behaviour. I'm not that well versed in portage internals, so I don't see *why* even is there a USE flag like "debug" or "strip" when these can be derived from the features. I can, however, imagine there is a reason for that, so I went with it when fixing the debug info installation (full vmlinux) as that was needed to make systemtap happy. Well, at least partially, the support is still subpar compared to other distributions. If I understand correctly the other related bug is more about this, so I'll post my findings there as well. However I can imagine being much more flexible if kernel-build.eclass based its behaviour on the FEATURES since for each installed file it ought to be pretty straightforward to see what needs to be done with it: - nostrip -- don't strip stuff in /boot and /lib/modules - splitdebug -- if there's debuginfo use objdump to put it in /usr/lib/debug/, ideally install symlinks in /usr/lib/debug/.build-id/ as well, but make sure the build-ids don't change (I was not sure how to do that which became one of the reasons to use `mv` for vmlinux installation) - installsources -- install sources to /usr/src/debug - compressdebug -- compress debugging information in /usr/lib/debug/ and so on. I must admit I am unaware of how feasible that is, so pardon my naivety.
(In reply to Martin Kletzander from comment #5) > Well, at least partially, the support is still subpar compared to other distributions. Will respond to the rest later (thank you Martin!), but if there's stuff you feel isn't covered by these two bugs, please feel free to file more. I want to get us to a point where systemtap is happy, even if it involves some bigger picture planning on our side.
If I understand correctly the other bug (for which I still included the comment in this one because I was in a hurry) is about making the experience better, so it should fall into the other one. Well, also this one. I'm not entirely sure what is the difference between these two. If we have the same behaviour for kernel.eclass as we do for FEATURES in all other ebuilds, then both of these might be closed? Or maybe one is about the BTF for which there might be another USE flag, but I have no idea whether that would be necessary or not.
