We're hoping to enable BTF by default as systemd[bpf] needs it, as does DTrace, and other profiling and tracing tools. One quirk is the complex interaction with USE=debug and USE=strip. Maybe we should always do BTF and have USE=debug control full debugging information (like DWARF), but by default, we'd strip and only keep '.BTF'. --- Split out from bug 938957: (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. (In reply to Sam James from comment #2) > (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.
Maybe we should live with the ugliness first and keep it as-is, then if +debug goes okay and nothing explodes for a bit, we can start to rework it and make things smaller as a bonus (with that change in bug 938957).
I should note that we do need to keep *some* mechanism of not-stripping vmlinux at all because systemtap and some other tools still need DWARF.
(In reply to Sam James from comment #0) > (In reply to Sam James from comment #2) > > (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. For context, the original reason to use '--strip-unneeded' here was because that is the same option that linux-mod-r1.eclass uses: _modules_process_strip() { # letting the package manager handle this complicates scenarios # where we want to either compress the pre-stripped module, or # sign the module without its signature becoming invalid on merge dostrip -x "${@#"${ED}"}" if use strip; then einfo "Stripping modules ..." edob "${KERNEL_STRIP}" --strip-unneeded -- "${@}" fi } I think we should try to keep the symmetry between in-tree and out-of-tree modules in this regard. So if we want to change this here, we should also make some adjustments to linux-mod-r1.eclass (maybe introduce USE=debug there too?).
ftr only reason linux-mod-r1 does unneeded was to mimic what portage was already doing to modules before we restricted stripping (aka for parity), so whatever seems better for modules can replace it. Haven't dug into these issues much, but at a glance I don't quite see what USE=debug in linux-mod-r1 would do though? Note modules will just build using the same settings as the kernel by default.
(In reply to Ionen Wolkens from comment #4) > Haven't dug into these issues much, but at a glance I don't quite see what > USE=debug in linux-mod-r1 would do though? Note modules will just build > using the same settings as the kernel by default. ...or is this about making this controllable independently from the kernel? Not sure if this would be useful given a lot of debug information would be missing without kernel's -- not that I know much about kernel/modules debugging.
> ...or is this about making this controllable independently from the kernel? That was what I was thinking of yes, similar to how USE=modules-sign and USE=modules-compress settings for out-of-tree modules are more or less independent from the kernels USE configuration.
