Re: [RFC 28/31] x86/alternative: Create symbols for special section entries

Peter Zijlstra
2024-09-04T08:08:44Z

On Tue, Sep 03, 2024 at 09:28:29PM -0700, Josh Poimboeuf wrote:
> On Tue, Sep 03, 2024 at 10:29:09AM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 02, 2024 at 09:00:11PM -0700, Josh Poimboeuf wrote:
> > > Create a symbol for each special section entry. This helps objtool
> > > extract needed entries.
> >
> > A little more explanation would be nice,..
>
> Indeed!
>
> From: Josh Poimboeuf <jpoimboe@kernel.org>
> Subject: [PATCH] x86/alternative: Create symbols for special section entries
>
> The kernel has a myriad of special sections including __bug_table,
> .altinstructions, etc. Each has its own distinct format, though each is
> more or less an array of structs or pointers.
>
> When creating a livepatch module, objtool extracts a subset of functions
> out of the original object file and into a new one. For that to work
> properly, it also needs to extract a subset of each special section's
> entries. Specifically, it should only extract those entries which
> reference the extracted functions.
>
> One way to achieve that would be to hardcode intimate knowledge about
> each special section and its entry sizes. That's less than ideal,
> especially for cases like .altinstr_replacement which has variable-sized
> "structs" which are described by another section.
>
> Take a more generic approach: for the "array of structs" style sections,
> annotate each struct entry with a symbol containing the entry. This
> makes it easy for tooling to parse the data and avoids the fragility of
> hardcoding section details.
>
> (For the "array of pointers" style sections, no symbol is needed, as the
> format is already self-evident.)

(so someone went and touched a ton of the alternative code recently,
this is going to need a rebase)

This generates a metric ton of symbols and I'm not seeing you touch
kallsyms.c, do we want to explicitly drop these from a --all-symbols
build? I don't think it makes sense to have them in the final image,
right?