On Thu, Aug 7, 2025 at 11:25 AM Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: > > > This is complementary to today's series from Alan Maguire, as we can use > the one liner for the kernel build process to test his series without > requiring installing a toolchain that generates BTF for each .o file > that will result in vmlinux. > > Next steps on my side are to: > > 1. change pahole for when it receives --format_path=btf check if > btf__is_archive(btf) is true, then just replace the current vmlinux .BTF > contents with the raw data in this just loaded BTF, short circuiting > the whole process. > > 2. the kernel build process should be changed to allow one to ask for > just BTF, not DWARF, and if so, using the above method, strip the DWARF > info after using it to generate BTF. > > Then when compilers are producing BTF, we switch to that, falling back > to the above method when a compiler is known to generate buggy BTF. > > And also to use in CIs, to compare the output generated by the various > methods in the various components. > > 3. In 2 we can even use the same scheme we use for parallelizing DWARF > loading when loading all the BTF archive members concatenated in vmlinux > to dedup them. 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?
