Skip to content

[pauthabi64] Require 0 addend for signing of undefined weak ref#391

Open
smithp35 wants to merge 2 commits into
ARM-software:mainfrom
smithp35:pauthweak
Open

[pauthabi64] Require 0 addend for signing of undefined weak ref#391
smithp35 wants to merge 2 commits into
ARM-software:mainfrom
smithp35:pauthweak

Conversation

@smithp35
Copy link
Copy Markdown
Contributor

@smithp35 smithp35 commented Apr 23, 2026

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

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
Comment thread pauthabielf64/pauthabielf64.rst Outdated
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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants