On August 8, 2025 3:28:13 PM GMT-03:00, Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
>On Thu, 2025-08-07 at 19:09 -0700, Alexei Starovoitov wrote:
>
>[...]
>
>> Before you jump into 1,2,3 let's discuss the end goal.
>> I think the assumption here is that this btf-for-each-.o approach
>> is supposed to speed up the build, right ?
>> pahole step on vmlinux is noticeable, but it's still a fraction
>> of three vmlinux linking steps.
>> How much are we realistically thinking to shave off of that pahole dedup time?
>
>Hi Alan, Arnaldo, Nick,
>
>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:
>
> for f in $(find . -name "*.o" | grep -Ev '(scripts|vmlinux|tools|module-common)'); do \
> readelf -SW $f | grep "\.debug";
> done \
> | awk 'BEGIN {val=0} {val += strtonum("0x"$6)} END {printf("%d", val)}' \
> | numfmt --to=si
>
>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.
>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.
> 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.
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.
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-)
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.
- Arnaldo
