[AAELF64] Make R_<CLS>_PREL32 and 16 signed.#401
Merged
Conversation
The existing definitions of these relocations have a hybrid range of -2^31 <= X < 2^32. This can make sense for the ABS (S+A) relocations so the result can be interpreted as signed or unsigned. However for the relative (S-P+A) relocations it is almost always going to be interpreted as signed as there is no guarantee of section ordering. Given that GNU ld has implemented the relative R_<CLS>_PREL32 relocation as signed and lld would like to follow suite redefine the overflow as a signed integer. Also correct R_<CLS>_PREL16 for the 16-bit case, using the same justification. Given that ELF64 is not short of relocation codes if there is a need for unsigned variants we can define new relocation codes.
Contributor
Author
|
LLD would like to follow GNU ld behaviour with llvm/llvm-project#205963 |
This was referenced Jun 29, 2026
Contributor
Author
|
Thanks will merge tomorrow to give some more time for any external comments. |
jrtc27
reviewed
Jul 1, 2026
| +---------+---------+----------------------+-----------+------------------------------------------------------------------+ | ||
|
|
||
| With the exception of ``R_<CLS>_PLT32``, these overflow ranges permit either signed or unsigned narrow values to be created from the intermediate result viewed as a 64-bit signed integer. If the place is intended to hold a narrow signed value and ``INTn_MAX < X <= UINTn_MAX``, no overflow will be detected but the positive result will be interpreted as a negative value. | ||
| For the relocations with a S + A operation, these overflow ranges permit either signed or unsigned narrow values to be created from the intermediate result viewed as a 64-bit signed integer. If the place is intended to hold a narrow signed value and ``INTn_MAX < X <= UINTn_MAX``, no overflow will be detected but the positive result will be interpreted as a negative value. |
Contributor
There was a problem hiding this comment.
This feels a bit indirect of a way to just say "For the R_<CLS>_ABSn relocations"? Also, arguably the other relocations do have an S + A operation nested inside an S + A - P one.
Contributor
Author
There was a problem hiding this comment.
My first draft said absolute relocations, then I'd need to define which ones were absolute and settled for S+A as that was the entry in the table.
Can try and reword using the relocation names and a prefix in a separate patch, likely next week though.
Contributor
There was a problem hiding this comment.
In principle this whole paragraph could be removed once we agree that ABS relocations are always unsigned (#402).
aeubanks
added a commit
to llvm/llvm-project
that referenced
this pull request
Jul 1, 2026
After ARM-software/abi-aa#401, these are defined to be only signed 32/16 bit ints rather than both signed and unsigned. Assisted-by: Gemini
llvm-sync Bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jul 1, 2026
After ARM-software/abi-aa#401, these are defined to be only signed 32/16 bit ints rather than both signed and unsigned. Assisted-by: Gemini
llvm-upstreamsync Bot
pushed a commit
to qualcomm/cpullvm-toolchain
that referenced
this pull request
Jul 1, 2026
After ARM-software/abi-aa#401, these are defined to be only signed 32/16 bit ints rather than both signed and unsigned. Assisted-by: Gemini
llvm-upstream-sync Bot
pushed a commit
to sriyalamar/cpullvm-toolchain
that referenced
this pull request
Jul 1, 2026
After ARM-software/abi-aa#401, these are defined to be only signed 32/16 bit ints rather than both signed and unsigned. Assisted-by: Gemini
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
3 participants
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.
The existing definitions of these relocations have a hybrid range of -2^31 <= X < 2^32. This can make sense for the ABS (S+A) relocations so the result can be interpreted as signed or unsigned.
However for the relative (S-P+A) relocations it is almost always going to be interpreted as signed as there is no guarantee of section ordering. Given that GNU ld has implemented the relative R_PREL32 relocation as signed and lld would like to follow suite redefine the overflow as a signed integer. Also correct R_PREL16 for the 16-bit case, using the same justification.
Given that ELF64 is not short of relocation codes if there is a need for unsigned variants we can define new relocation codes.