Re: [PATCH 04/23] kallsyms: output binary data to speed output and kallsyms assembly

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Wed, Sep 09, 2026 at 07:35:16AM -0700, Linus Torvalds wrote:
> I'm finally going through this series, because I do care about build
> speed, so I love the concept.
>
> However, I haven't actually applied it and tried it, I'm just reading
> the patches.
>
> And this one triggered something:
>
> On Tue, 8 Sept 2026 at 13:56, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> >
> > kallsyms generates an assembly file that consists mostly of .byte entries
> > containing compressed names, token strings and name-sorted sequence
> > numbers.
> >
> > For an x86-64 build with 158k symbols that is a 37 MiB .S file which takes
> > 0.57s to assemble each of the two to three times it is built over a kernel
> > build.
>
> It strikes me that this is clearly a bit faster, but it still seems to
> be not really fixing the underlying silliness of that code.
>
> Wouldn't it be much better to actually create an object file directly?
> Afaik, the *only* think we ever do with that kallsyms-generated file
> is to immediately assemble it into an object file, because the actual
> asm file is useless to anybody.
>
> And we already require libelf as part of the build, and we already
> kind of do things like that with gendwarfksyms.
>
> Don't get my wrong: I think going through an asm file was very much
> the right thing originally: not every architecture used ELF in the
> first place, and when scripting things like this the current situation
> makes 100% sense.
>
> And no sane human wants to deal with this kind of grotty detail and
> spend the effort on writing an ELF file writer.
>
> But when there's a LLM that was used to find these things and help fix
> them up, and it's something this mechanical and the result really
> isn't ever human-readable and never has been, I feel like the obvious
> step would be to just ask the little helper bot to switch the whole
> kallsyms to using libelf-devel and writing an object file directly.
>
> I don't think anybody has any deep emotional ties to the current
> kallsyms code and that horrific step of the kernel build, do they?

No, but I wonder if it's really worth going all the way. And I did ask the LLM
about this too (of course :)

The way it works now there's still a bunch of .long offset entries in the
assembly which can actually be put into the binary file (the series generates a
binary file for the byte tables and includes using .incbin).

So mostly it's binary already.

If we tried to generate an ELF file directly there'd be complications (LLM says
e_flags and fun with arch-specific ABIs, plus arch's relocation type for
_text-relative base).

I don't think there'd be much of a win for the added complexity (and I am
nervous of fiddling with arch-specific stuff), BUT, can definitely put
those remaining .long entries in the binary too so the assembly is
absolutely minimal.

LLM says there's 200k of those, so does seem worthwhile, I'll do that for
v2!

>
>                Linus

--
Cheers, Lorenzo