On Fri, 2025-08-08 at 16:10 -0300, Arnaldo Carvalho de Melo wrote: [...] > > I'd like to second Alexei's question. > > In the cover letter Arnaldo points out that un-deduplicated BTF > > amounts for 325Mb, while total DWARF size is 365Mb. > > I tried measuring total amount of DWARF in my kernel building directory: [...] > > And it says 845M. > > The size of DWARF sections in the final vmlinux is comparable to yours: 307Mb. > > The total size of the generated binaries is 905Mb. > > So, unless the above calculations are messed up, the total gain here is: > > - save ~500Mb generated during build > > - save some time on pahole not needing to parse/convert DWARF > > Well, this 845M number includes modules, that I didn't take into > account in my quick calculation for both DWARF and BTF. Sorry about that. I have just a few in my config, for those about 6Mb of DWARF is generated. > > Is this is what you are trying to achieve? > > > In theory, having BTF handled completely by compiler and linker makes > > sense to me. > > It looks right, no? But it's not efficient as BTF, as you point out > in your next paragraph, can be generated from DWARF, so better do it > as a final step if we want to have DWARF _and_ BTF. Idk, I'd stick to a single way of generating BTF, either using an old scheme or a new scheme. Allowing both will add one more variable when debugging BPF/BTF related issues reported from distros. > > However, pahole is already here and it does the job. > > So, I see several drawbacks: > > - As you note, there would be two avenues to generate BTF now: > > - DWARF + pahole > > - BTF + pahole (replaced by BTF + ld at some point?) > > This is a potential source of bugs. > > Is the goal to forgo DWARF+pahole at some point in the future? > > I think the goal is to allow DWARF less builds, which can probably > save time even if we do use pahole to convert DWARF generated from > the compiler into BTF and right away strip DWARF. > > This is for use cases where DWARF isn't needed and we want to for > example have CI systems running faster. Ack, thank you for clarification. > My initial interest was to do minimal changes to pave the way for > BTF generated for vmlinux directly from the compiler, but the > realization that DWARF still has a lot of mileage, meaning distros > will continue to enable it for the foreseeable future makes me think > that maybe doing nothing and continue to use the current method is > the sensible thing to do. > > > - I assume that it is much faster to land changes in pahole compared > > to changes in gcc, so future btf modifications/features might be a > > bit harder to execute. Wdyt? > > Right, that too, even if we enable generation of BTF for native .o > files by the compiler we would still want to use pahole to augment > it with new features or to fixup compiler BTF generation bugs. And > maybe for generating tags that are only possible to have the > necessary info at the last moment. > > So something that looked like a hack seems not to really be one. Agree. > Then there's Gentoo, the one that likes the idea of a DWARF less > build... I like that too, so will continue working on this 8-) Out of curiosity, w/o DWARF how do you debug issues when something goes wrong? > Now if we could have hooks in the linker associated with a given ELF > section name (.BTF) to use instead of just concatenating, and then > at the end have another hook that would finish the process by doing > the dedup, just like I do in this series, that would save one of > those linker calls. > > I did some quick research and couldn't find such infrastructure in > the linkers, I think this is a sensible path, use the minimal > changes in my patch series to have a .so plugin to use with a linker > that supports this, but then this, again, would make sense only for > a BTF only build. LD documentation page mentions existence of plugins [1], but after a cursory look at the source code I'm unable to tell how easy/hard/possible is BTF modification from such a plugin. [1] https://sourceware.org/binutils/docs/ld.html#Plugins
