create-diff-object: handle R_X86_64_32 in rela_target_offset - #1516
Open
benjamindonnachie wants to merge 1 commit into
Open
create-diff-object: handle R_X86_64_32 in rela_target_offset#1516benjamindonnachie wants to merge 1 commit into
benjamindonnachie wants to merge 1 commit into
Conversation
rela_target_offset() treats R_X86_64_64 and R_X86_64_32S as absolute (non-PC-relative) relocations needing no instruction-decode-based offset adjustment, but was missing R_X86_64_32 (ELF reloc type 10). Any file containing one hits "ERROR: unhandled rela type 10" and aborts the whole build. R_X86_64_32 and R_X86_64_32S are both absolute relocations; per the x86-64 psABI they differ only in how the linker validates/truncates the value during relocation *application* (zero- vs sign-extension), which has no bearing on add_off here -- the instruction-decode adjustment this function computes only matters for PC-relative encodings. So R_X86_64_32 belongs in the same branch as R_X86_64_32S. R_X86_64_32 shows up in low-level x86 code that still executes in 32-bit protected mode before the switch to long mode (observed in arch/x86/platform/pvh/head.o, Xen PVH boot entry), where the usual 64-bit-oriented relocations don't apply. Reproduced and fixed while building a real cumulative EL9 5.14 kernel livepatch. Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #1514.
rela_target_offset()treatsR_X86_64_64andR_X86_64_32Sasabsolute (non-PC-relative) relocations needing no
instruction-decode-based offset adjustment, but was missing
R_X86_64_32(ELF reloc type 10). Any file containing one hitsERROR: unhandled rela type 10and aborts the whole build.R_X86_64_32andR_X86_64_32Sare both absolute relocations; perthe x86-64 psABI they differ only in how the linker
validates/truncates the value during relocation application
(zero- vs sign-extension), which has no bearing on
add_offhere —the instruction-decode adjustment this function computes only
matters for PC-relative encodings. So
R_X86_64_32belongs in thesame branch as
R_X86_64_32S.R_X86_64_32shows up in low-level x86 code that still executes in32-bit protected mode before the switch to long mode (observed in
arch/x86/platform/pvh/head.o, Xen PVH boot entry — see #1515 for atargeted exclusion of that file from diffing entirely, since it can
never be livepatchable, but this relocation-type gap is real and
independent of that).
Testing
Reproduced and fixed while building a real cumulative EL9 5.14
kernel livepatch. See #1514 for full context.
Co-authored-by: Claude noreply@anthropic.com