[pauthabi64] Require 0 addend for signing of undefined weak ref#391
Open
smithp35 wants to merge 2 commits into
Open
[pauthabi64] Require 0 addend for signing of undefined weak ref#391smithp35 wants to merge 2 commits into
smithp35 wants to merge 2 commits into
Conversation
When there is a non-zero addend to an undefined weak-reference then do not apply the rule the the result of the relocation is 0 regardless of the signing schema. The intent was that null-pointers could be easily tested for without worrying about signing schemas. However if there was a non-zero addend the result of the relocation, outside the pauthabi would be non-zero and hence wouldn't be a null-pointer. Clarify that the relocation addend must also be 0 for the result of the relocation to be 0, regardless of signing-schema. Raised from: llvm/llvm-project#173296
jrtc27
reviewed
Apr 23, 2026
Comment on lines
+681
to
+684
| For a relocation that involves signing a pointer, and the relocation | ||
| addend is 0, if the target symbol is an undefined weak reference, the | ||
| result of the relocation is 0 (nullptr) regardless of the signing | ||
| schema. |
Contributor
There was a problem hiding this comment.
Unless there's something else in the spec saying what to do for undefined symbols, I think this would imply that if the addend is non-zero you should sign the pointer as if the symbol were defined? Perhaps something more like this?
Suggested change
| For a relocation that involves signing a pointer, and the relocation | |
| addend is 0, if the target symbol is an undefined weak reference, the | |
| result of the relocation is 0 (nullptr) regardless of the signing | |
| schema. | |
| For a relocation that involves signing a pointer, if the target symbol is an undefined weak reference, the | |
| result of the relocation is not signed. If the relocation addend is 0, this means the result of the relocation is 0 (nullptr) regardless of the signing schema. |
Contributor
Author
There was a problem hiding this comment.
Thanks for the suggestion, looks like I misinterpreted the original issue when coming back to it. I've adopted the suggestion and will update the title and description to match.
kovdan01
added a commit
to llvm/llvm-project
that referenced
this pull request
May 12, 2026
… symbols Undefined weak non-preemptible symbols should be statically resolved to the addend value and not signed. Previously, a dynamic relocation against such symbols was emitted, which is not a correct behavior. See also docs: ARM-software/abi-aa#391 Resolves #173296
kovdan01
added a commit
to llvm/llvm-project
that referenced
this pull request
May 18, 2026
… symbols Undefined weak non-preemptible symbols should be statically resolved to the addend value and not signed. Previously, a dynamic relocation against such symbols was emitted, which is not a correct behavior. See also docs: ARM-software/abi-aa#391 Resolves #173296
kovdan01
added a commit
to llvm/llvm-project
that referenced
this pull request
May 25, 2026
… symbols Undefined weak non-preemptible symbols should be statically resolved to the addend value and not signed. Previously, a dynamic relocation against such symbols was emitted, which is not a correct behavior. See also docs: ARM-software/abi-aa#391 Resolves #173296
kovdan01
added a commit
to llvm/llvm-project
that referenced
this pull request
May 25, 2026
… symbols Undefined weak non-preemptible symbols should be statically resolved to the addend value and not signed. Previously, a dynamic relocation against such symbols was emitted, which is not a correct behavior. See also docs: ARM-software/abi-aa#391 Resolves #173296
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.
Clarify that undefined weak-references are unsigned.
The intent was that null-pointers could be easily tested for without worrying about signing schemas, if there is an unresolved weak-reference with a non-zero addend then the resulting value doesn't make a lot of sense, signed or unsigned. In practice to use a weak-reference with an addend it must be tested first with a zero addend.
if (weak) {
use weak->addend;
}
Raised from: llvm/llvm-project#173296