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@xxxxxxxxxx> > 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?
