Re: [RFC 0/4] BTF archive with unmodified pahole+toolchain

[Eduard Zingerman <eddyz87@gmail.com>]

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