Fix relocation addend sign extension on 32-bit platforms#4846
Open
sumleo wants to merge 1 commit intobytecodealliance:mainfrom
Open
Fix relocation addend sign extension on 32-bit platforms#4846sumleo wants to merge 1 commit intobytecodealliance:mainfrom
sumleo wants to merge 1 commit intobytecodealliance:mainfrom
Conversation
When loading relocations on 32-bit platforms, the addend is read as uint32 and zero-extended to uint64, which corrupts negative addends. For example, -4 (0xFFFFFFFC) becomes 4294967292 instead of remaining -4. Use int32 with sign extension to int64, matching the Windows code path which already handles this correctly.
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
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.
Summary
On 32-bit platforms,
load_relocation_sectionreads the relocation addend asuint32and zero-extends it touint64. This corrupts negative addends — for example, an addend of -4 (0xFFFFFFFCas a 32-bit value) becomes4294967292instead of remaining-4(0xFFFFFFFFFFFFFFFCas a 64-bit value).The Windows code path (around line 3616) already handles this correctly by declaring the addend as
int32and casting toint64, which performs proper sign extension.Changes
addend32fromuint32toint32soread_uint32populates it with the correct bit pattern(uint64)to(int64)so negative values are sign-extended rather than zero-extendedoffset32variable remainsuint32since relocation offsets are unsignedTest plan
sizeof(void *) != 8)