On Thu, Jun 15, 2023 at 1:35 PM Dominique Martinet <asmadeus@xxxxxxxxxxxxx> wrote: > > > Alan Maguire wrote on Thu, Jun 15, 2023 at 03:31:49PM +0100: > > However the problem I suspect is this: > > > > 51 .debug_info 0a488b55 0000000000000000 0000000000000000 026f8d20 > > 2**0 > > CONTENTS, READONLY, DEBUGGING > > [...] > > > > The debug info hasn't been stripped, so I suspect the packaging spec > > file or equivalent - in perhaps trying to preserve the .BTF section - > > is preserving debug info too. DWARF needs to be there at BTF > > generation time in vmlinux but is usually stripped for non-debug > > packages. > > Thanks Alan and Eduard! > I guess I should have checked that first, it helps. > > We're not stripping anything in vmlinuz for other archs -- the linker > script already should be including only the bare minimum to decompress > itself (+compressed useful bits), so I guess it's a Kbuild issue for the > arch. > We can add a strip but I unfortunately have no way of testing ppc build, > I'll ask around the build linux-kbuild and linuxppc-dev lists if that's > expected; it shouldn't be that bad now that's figured out. > > > > FYI we're aiming to make BTF module-loadable via CONFIG_DEBUG_INFO_BTF=m > > in the future, I'm hoping to get an RFC patch out for that soon once > > other BTF-related issues are sorted. Hope this helps > Besides this, in the past it was requested a few times to make CONFIG_DEBUG_INFO_BTF=y not imply CONFIG_DEBUG_INFO_DWARF. That is, make it possible to get BTF without .dwarf* sections being left in the vmlinux image. Of course, implementation-wise, DWARF would still have to be generated at runtime, but would be automatically stripped out after BTF generation, unless CONFIG_DEBUG_INFO_DWARF* is set. I think it would help in this case as well. So if anyone has free cycles, it would be awesome to make this possible. > Oh, that's interesting -- I assume that'll only change the 'built-in' > BTF info? Or will that also split BTF info in other modules as > e.g. modfoo_btf.ko? > For x86_64 the size increase of vmlinuz itself is rather acceptable > (<2MB), but the sheer amount of modules (the -lts package has over 3k > modules...) means that even a small size increase for each module ends > up taking proportionally a high amount of space (+20MB from 90MB), so > being able to package separately would be appreciated (alpine likes > splitting optional features in subpackages) > Packaging-wise I'm not sure it'd make sense to keep the overhead in > other modules and just split the 'main' btf infos. > > Otoh even if it doesn't help with packaging, having a smaller vmlinuz > means faster boot and lower kernel memory footprint (I think *2?) for > people who don't need it, so I think it's a good idea and we'll probably > enable it once it becomes available. Thanks for the heads up! > > -- > Dominique Martinet | Asmadeus >
