Skip to content

Fix relocation addend sign extension on 32-bit platforms#4846

Open
sumleo wants to merge 1 commit intobytecodealliance:mainfrom
sumleo:fix/relocation-addend-sign-extension
Open

Fix relocation addend sign extension on 32-bit platforms#4846
sumleo wants to merge 1 commit intobytecodealliance:mainfrom
sumleo:fix/relocation-addend-sign-extension

Conversation

@sumleo
Copy link
Contributor

@sumleo sumleo commented Feb 25, 2026

Summary

On 32-bit platforms, load_relocation_section reads the relocation addend as uint32 and zero-extends it to uint64. This corrupts negative addends — for example, an addend of -4 (0xFFFFFFFC as a 32-bit value) becomes 4294967292 instead of remaining -4 (0xFFFFFFFFFFFFFFFC as a 64-bit value).

The Windows code path (around line 3616) already handles this correctly by declaring the addend as int32 and casting to int64, which performs proper sign extension.

Changes

  • Changed addend32 from uint32 to int32 so read_uint32 populates it with the correct bit pattern
  • Changed the cast from (uint64) to (int64) so negative values are sign-extended rather than zero-extended
  • The offset32 variable remains uint32 since relocation offsets are unsigned

Test plan

  • Verified that the fix matches the existing Windows code path behavior
  • The change only affects 32-bit platforms (sizeof(void *) != 8)
  • Negative relocation addends (e.g., used for GOT-relative relocations) will now be preserved correctly

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant