Hi Peter,
On 9/29/25 4:19 PM, Peter Zijlstra wrote:
On Mon, Sep 29, 2025 at 01:34:54PM +0530, Sathvika Vasireddy wrote:
Implement build-time fixup of alternate feature relative addresses for
the out-of-line (else) patch code. Initial posting to achieve the same
using another tool can be found at [1]. Idea is to implement this using
objtool instead of introducing another tool since it already has elf
parsing and processing covered.
Introduce --ftr-fixup as an option to objtool to do feature fixup at
build-time.
Couple of issues and warnings encountered while implementing feature
fixup using objtool are as follows:
1. libelf is creating corrupted vmlinux file after writing necessary
changes to the file. Due to this, kexec is not able to load new
kernel.
It gives the following error:
ELF Note corrupted !
Cannot determine the file type of vmlinux
To fix this issue, after opening vmlinux file, make a call to
elf_flagelf (e, ELF_C_SET, ELF_F_LAYOUT). This instructs libelf not
to touch the segment and section layout. It informs the library
that the application will take responsibility for the layout of the
file and that the library should not insert any padding between
sections.
2. Fix can't find starting instruction warnings when run on vmlinux
Objtool throws a lot of can't find starting instruction warnings
when run on vmlinux with --ftr-fixup option.
These warnings are seen because find_insn() function looks for
instructions at offsets that are relative to the start of the section.
In case of individual object files (.o), there are no can't find
starting instruction warnings seen because the actual offset
associated with an instruction is itself a relative offset since the
sections start at offset 0x0.
However, in case of vmlinux, find_insn() function fails to find
instructions at the actual offset associated with an instruction
since the sections in vmlinux do not start at offset 0x0. Due to
this, find_insn() will look for absolute offset and not the relative
offset. This is resulting in a lot of can't find starting instruction
warnings when objtool is run on vmlinux.
To fix this, pass offset that is relative to the start of the section
to find_insn().
find_insn() is also looking for symbols of size 0. But, objtool does
not store empty STT_NOTYPE symbols in the rbtree. Due to this,
for empty symbols, objtool is throwing can't find starting
instruction warnings. Fix this by ignoring symbols that are of
size 0 since objtool does not add them to the rbtree.
3. Objtool is throwing unannotated intra-function call warnings
when run on vmlinux with --ftr-fixup option.
One such example:
vmlinux: warning: objtool: .text+0x3d94:
unannotated intra-function call
.text + 0x3d94 = c000000000008000 + 3d94 = c0000000000081d4
c0000000000081d4: 45 24 02 48 bl c00000000002a618
<system_reset_exception+0x8>
c00000000002a610 <system_reset_exception>:
c00000000002a610: 0e 01 4c 3c addis r2,r12,270
c00000000002a610: R_PPC64_REL16_HA .TOC.
c00000000002a614: f0 6c 42 38 addi r2,r2,27888
c00000000002a614: R_PPC64_REL16_LO .TOC.+0x4
c00000000002a618: a6 02 08 7c mflr r0
This is happening because we should be looking for destination
symbols that are at absolute offsets instead of relative offsets.
After fixing dest_off to point to absolute offset, there are still
a lot of these warnings shown.
In the above example, objtool is computing the destination
offset to be c00000000002a618, which points to a completely
different instruction. find_call_destination() is looking for this
offset and failing. Instead, we should be looking for destination
offset c00000000002a610 which points to system_reset_exception
function.
Even after fixing the way destination offset is computed, and
after looking for dest_off - 0x8 in cases where the original offset
is not found, there are still a lot of unannotated intra-function
call warnings generated. This is due to symbols that are not
properly annotated.
So, for now, as a hack to curb these warnings, do not emit
unannotated intra-function call warnings when objtool is run
with --ftr-fixup option.
Should not all those fixes be split out into separate patches?
Thank you for reviewing. You're right - these fixes should be split into
separate patches.
Also,
Changelog seems to have lost the bit where you explain *why* you need
this. IIRC Nick's original tool had a description of why this is needed.
Yes, Nick's original patch has the description on why this is needed:
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/
Currently __ftr_alt* sections must be near .text because they lack the
executable attribute (preventing linker stubs), requiring branches to
reach targets directly. This may cause build failures as the kernel
grows. To solve this, the approach uses --emit-relocs to preserve
relocation information, marks sections executable (allowing stubs), and
fixes branch offsets at build time based on their runtime locations.
This implementation uses objtool with the --ftr-fixup option instead of
a new tool, since objtool already has ELF parsing and instruction
patching infrastructure. I'll include the details of why this is needed
in the Changelog in the next version I send.
Also, please see:
https://lkml.kernel.org/r/9500b90c4182b03da59472e1a27876818610b084.1758067942.git.jpoim...@kernel.org
https://lkml.kernel.org/r/457c2e84b81bd6515aaa60ec8e9e0cc892ed7afa.1758067942.git.jpoim...@kernel.org
Sure, will check.
Thanks,
Sathvika
