[PAuthABIELF64] Clarify the interaction between Memtag and PAuthAbi #366
Conversation
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
The PAuthABI introduces some new dynamic relocations and the MemtagABI adds additional semantics to existing core dynamic relocations. The additional semantics for MemtagABI can be applied to the new PAuthABI dynamic relocations. In most cases the extension is natural as the LDG and SIGN operations operate on different bits in the pointer and can apply in either order. Both the MemtagABI and the PAuthABI require additional metadata for the R_AARCH64_AUTH_RELATIVE relocation which is stored in the place of the relocation. The MemtagABI stores an additional addend compensator so that the dynamic linker can derive the start address of the datatype so that it can materialize the correct tag. The PAuthABI stores the signing schema, including an addend field which contains the relocation addend when RELR compression is used. As the MemtagABI excludes any relocations with an addend compensator from RELR compression, and PAuthABI requires the addend field in the signing schema to be 0 when RELR compression is not used; we can use the signing schema addend field for the Memtag addend compensator. Document the relocation operators and how the MemtagABI applies to the PAuthABI relocations. This behaviour was implemented in LLD PR llvm/llvm-project#173291
jrtc27
approved these changes
Feb 6, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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 PAuthABI introduces some new dynamic relocations and the MemtagABI adds additional semantics to existing core dynamic relocations.
The additional semantics for MemtagABI can be applied to the new PAuthABI dynamic relocations. In most cases the extension is natural as the LDG and SIGN operations operate on different bits in the pointer and can apply in either order.
Both the MemtagABI and the PAuthABI require additional metadata for the R_AARCH64_AUTH_RELATIVE relocation which is stored in the place of the relocation. The MemtagABI stores
an additional addend compensator so that the dynamic linker can derive the start address of the datatype so that it can materialize the correct tag. The PAuthABI stores the signing schema, including an addend field which contains the relocation addend when RELR compression is used. As the MemtagABI excludes any relocations with an addend compensator from RELR compression, and PAuthABI requires the addend field in the signing schema to be 0 when RELR compression is not used; we can use the signing schema addend field for the Memtag addend compensator.
Document the relocation operators and how the MemtagABI applies to the PAuthABI relocations.
This behaviour was implemented in LLD PR
llvm/llvm-project#173291