[PATCH] D156505: [AArch64][ELF] Support R_AARCH64_AUTH_ABS64 static relocation

Wed Aug 16 22:39:11 PDT 2023

MaskRay added a comment.

Being unable to reuse the generic `AsmParser::parsePrimaryExpr` `if (!MAI.useParensForSymbolVariant())` makes me nervous, but I think this is probably fine.
However, I think we need some unary/binary operator tests like `1 + sym at AUTH(ia,42) + 1`.

================
Comment at: llvm/docs/PointerAuth.md:308
+[Authenticated Relocations](#authenticated-global-relocation) are represented
+using the ``@AUTH`` modifier:
+
----------------
This file is a Markdown. Single backquotes are more commonly used.

================
Comment at: llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp:7541
+  if (!isUInt<16>(Discriminator))
+    return TokError("too wide integer discriminator '" + Twine(Discriminator) +
+                    "'");
----------------
kovdan01 wrote:
> peter.smith wrote:
> > Similar error messages use out of range. Ideally we should give the permitted range in the error message.
> > `integer discriminator <Discrimator> is out of range, [0, 65535] expected` 
> It makes sense, changed the message, thanks. I used hex values since they look nicer and more readable in this context.
Peter's suggestion does not contain a period, which is more conventional.

Other used formats include `is not within [..., ...]` (`.subsections`) and `is not in [..., ...]` (lld/ELF)

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp:342
+        auto *Expr = cast<AArch64AuthMCExpr>(Fixup.getValue());
+        uint16_t Discriminator = Expr->getDiscriminator();
+        AArch64PACKey::ID Key = Expr->getKey();
----------------
The two used-once variables can be removed.

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp:344
+        AArch64PACKey::ID Key = Expr->getKey();
+
+        return (uint32_t(Value) << 0) |
----------------
delete blank line

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp:425
+  // kind. So, need to call adjustFixupValue even if the value is zero.
+  if (!Value && Fixup.getTargetKind() != FK_Data_8)
     return; // Doesn't change encoding.
----------------
I think this condition can be removed if we move custom code `adjustFixupValue` to this function. See the next comment.

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp:437
+  // The fixup is not related to VK_AUTH or VK_AUTHADDR. Skip.
+  if (!Value && Fixup.getTargetKind() == FK_Data_8)
+    return; // Doesn't change encoding.
----------------
We shouldn't have two conditions for FK_Data_8.

We probably should move the custom code from adjustFixupValue to here.

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp:331
+          SymLoc == AArch64AuthMCExpr::VK_AUTHADDR) {
+        // TODO: implement test with rel relocations and non-zero wide addends
+        // By default, rela is used, and implicit addend is 0
----------------
kovdan01 wrote:
> peter.smith wrote:
> > I'm not sure if MC can easily generate a REL relocation for AArch64. IIRC REL format may occur in the dynamic case, for RELATIVE compression and REL format dynamic relocations (lld -z rel).
> > 
> I added a TODO for checking if such case is even possible. I think that the if statement should be kept since the ABI explicitly says that those bits are used for addend on platforms with rel. 
> 
> Thanks for mentioning the dynamic case (`lld -z rel`). I'll check it, but it's out of scope of this patch so mark the comment as done. Feel free to re-open it if needed.
You can delete TODO.

AArch64ELFObjectWriter uses `/*HasRelocationAddend*/ true`.

You may use an assert instead.

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp:336
+                                          Twine(Value) +
+                                          "' in auth relocation");
+
----------------
kovdan01 wrote:
> peter.smith wrote:
> > Worth saying what the range is in the error message? For example there are other error messages with `fixup value out of range [-0xFFFF, 0xFFFF]");` For example:
> > "out of range addend <Value> in auth relocation. Permitted range [-2,147,483,648, -2,147,483,647]"
> Fixed, thanks. I also used hex values here: although most people are familiar with decimal representation of these values, they are more messy than their hex variants.
Sorry for the bikeshedding, but I think out-of-range diagnostics don't usually contain a period.

Something like `auth relocation addend <Value> out of range [...,...]` may be better.

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.cpp:158
+
+//===----------------------------------------------------------------------===//
+
----------------
delete

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.h:20
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/Casting.h"

----------------
clang-format should move Casting.h before ErrorHandling.h

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.h:180
+
+class AArch64AuthMCExpr : public AArch64MCExpr {
+  uint16_t Discriminator;
----------------

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.h:190
+public:
+  /// @name Construction
+  /// @{
----------------
These annotations provide very little value. I think we discourage them for newer code to make classes more compact.

================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.h:198
+  /// @}
+  /// @name Accessors
+  /// @{
----------------
ditto

================
Comment at: llvm/test/MC/AArch64/ptrauth-elf-reloc.s:1
+// RUN: split-file %s %t
+
----------------
To following the convention of test naming, this probably should be `elf-reloc-ptrauth.s`

================
Comment at: llvm/test/MC/AArch64/ptrauth-elf-reloc.s:6
+// RUN: llvm-mc -triple=aarch64 %t/ok.s | \
+// RUN: FileCheck %s --check-prefix=ASM
+
----------------
ditto

actually, this line is so short that we should not use continuation

================
Comment at: llvm/test/MC/AArch64/ptrauth-elf-reloc.s:9
+// RUN: llvm-mc -triple=aarch64 -filetype=obj %t/ok.s | \
+// RUN: llvm-readelf -S -r -x .test - | \
+// RUN: FileCheck %s --check-prefix=RELOC
----------------
continuation lines are indented by 2 by convention

================
Comment at: llvm/test/MC/AArch64/ptrauth-elf-reloc.s:94
+
+// RUN: not llvm-mc -triple=aarch64 %t/err1.s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=ERR1
----------------
kovdan01 wrote:
> MaskRay wrote:
> > llvm-mc has error recovery. You can test all errors in one llvm-mc invocation, instead of using many `err*.s`
> Fixed, thanks
Sorry that I didn't mention another point. When we have just one patch of negative tests, we can just wrap them with

```
.ifdef ERR
...
...
.endif
```

and then we can avoid invoking split-file.

You can grep `def ERR` in test/MC to find many newer tests I added.

================
Comment at: llvm/test/MC/AArch64/ptrauth-elf-reloc.s:97
+
+// ERR1: error: expected '('
+
----------------
kovdan01 wrote:
> MaskRay wrote:
> > Newer tests are recommended to test the line/column information like:
> > 
> > ```
> > // ERR: :[[#@LINE+1]]:10: error: expected '('
> > .quad sym at AUTH)ia,42)
> > ```
> Applied this, thanks
`[[#@LINE-77]]` may not be a good choice. If we add more lines before the checks, the `-77` part will need adjustment.

My original suggestion is
```
// ERR: :[[#@LINE+1]]:10: error: expected '('
.quad sym at AUTH)ia,42)

// ERR: :[[#@LINE+1]]:10: error: ...
.quad ...
```

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156505/new/

https://reviews.llvm.org/D156505