On August 8, 2025 5:15:34 PM GMT-03:00, Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: >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. Initial numbers, I'll try and have some more comprehensive way to collect the relevant numbers and be able to compare approaches. >> > 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. Well, I understand the push to pool scarce developer resources to get one way of doing things, be it using pahole or the tool chain (compiler + linker). But at the same time having multiple ways to do the same thing, like we have with multiple compilers and linkers is a good thing (tm). With multiple ways, developed mostly independently in ways some camps think hackish, we can give the people working in CI systems more job sekurity, build in many ways and see if differences are bugs, i.e. we want reliable info for co-re, etc, so having multiple producers and continuously comparing their results seems desirable. Sure, at should see what's the fastest, most reliable by track record, cheapest way to produce both DWARF and BTF and use it. Right now, among the schemes being discussed, it's what we have in place. Good. >> > 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? Well, modern tooling support BTF when debugging/tracing/etc the _kernel_, see drgn, perf, and now even ftrace. Look ma, no DWARF :-) >> 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. Yeah, linking looked like something done with, no need for this kind of extensibility. Nope, we need it now. - Arnaldo > >[1] https://sourceware.org/binutils/docs/ld.html#Plugins - Arnaldo
