[llvm-branch-commits] [NFCI][ELF][AArch64][PAC] Teach addRelativeReloc to emit R_AARCH64_AUTH_RELATIVE (PR #171180)

[Peter Smith via llvm-branch-commits]

================
@@ -704,8 +704,10 @@ static void addRelativeReloc(Ctx &ctx, InputSectionBase &isec,
                              uint64_t offsetInSec, Symbol &sym, int64_t addend,
                              RelExpr expr, RelType type) {
   Partition &part = isec.getPartition(ctx);
+  bool isAArch64Auth =
+      ctx.arg.emachine == EM_AARCH64 && type == R_AARCH64_AUTH_ABS64;
 
-  if (sym.isTagged()) {
+  if (sym.isTagged() && !isAArch64Auth) {
----------------
smithp35 wrote:

The TL;DR is that in theory they could be combined. In practice no-one has tried combining or expressed an interest in combining them. One opinion is that it could be removed for now, and when someone does try it, they'll need to put something similar back. Perhaps leave a comment.

>From a user group perspective the PAuthABI and the MemtagABI communities are separate. As I understand the PAuthABI is an ABI break for the group using Memtag and the group intending to use PAuthABI is targeting hardware that doesn't have MTE so can't use the Memtag ABI anyway.

Re-reading the specifications I don't think that there's anything fundamental at the specification level that would prevent the two being used together. The PAuthABI adds new relocations, the MemtagABI alters the behaviour of existing non PAuth ABI relocations. This means that global signed pointers can't be tagged, but as tagging does not have to be complete, anything that isn't signed could be tagged.

I expect that the memtag ABI could be extended to cover signed pointers. It would need to encode the tag offset for relative relocations for R_AARCH64_AUTH_RELATIVE in a compatible way to the signing schema.

https://github.com/llvm/llvm-project/pull/171180