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
Is this is what you are trying to achieve?
In theory, having BTF handled completely by compiler and linker makes
sense to me. 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 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?
Thanks,
Eduard
