[PATCH] D156505: [AArch64][ELF] Support R_AARCH64_AUTH_ABS64 static relocation
Daniil Kovalev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 18 08:17:20 PDT 2023
kovdan01 added a comment.
TODO: add more unary/binary operator tests like `1 + sym at AUTH(ia,42) + 1`, `sym at AUTH(ia,0) + sym at AUTH(ia,0)`.
================
Comment at: llvm/docs/PointerAuth.md:308
+[Authenticated Relocations](#authenticated-global-relocation) are represented
+using the ``@AUTH`` modifier:
+
----------------
MaskRay wrote:
> This file is a Markdown. Single backquotes are more commonly used.
I agree with that, but double backquotes are already used in other places in this file.
I suggest to leave this 'as is' in context of current patch and submit a small subsequent patch changing double- to single backquote all over the file.
================
Comment at: llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp:7541
+ if (!isUInt<16>(Discriminator))
+ return TokError("too wide integer discriminator '" + Twine(Discriminator) +
+ "'");
----------------
MaskRay wrote:
> 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)
Changed to `integer discriminator <disc> out of range [..., ...]` as such variant seems to be both compact and widely-used in lld. Thanks for providing the examples.
================
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();
----------------
MaskRay wrote:
> The two used-once variables can be removed.
Fixed
================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp:344
+ AArch64PACKey::ID Key = Expr->getKey();
+
+ return (uint32_t(Value) << 0) |
----------------
MaskRay wrote:
> delete blank line
Fixed
================
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.
----------------
MaskRay wrote:
> I think this condition can be removed if we move custom code `adjustFixupValue` to this function. See the next comment.
This is more convenient, fixed, thanks.
================
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
----------------
MaskRay wrote:
> 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.
If I got your point correctly, we can even check that the value is exactly 0. With rela, the value must be exactly 0, not just a 32-bit integer. Please let me know if I got you right.
================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64AsmBackend.cpp:336
+ Twine(Value) +
+ "' in auth relocation");
+
----------------
MaskRay wrote:
> 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.
Got it, thanks. Fixed other error messages. This one seems to be obsolete when keeping the following in mind:
> You can delete TODO.
> AArch64ELFObjectWriter uses `/*HasRelocationAddend*/ true`.
> You may use an assert instead.
================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.cpp:158
+
+//===----------------------------------------------------------------------===//
+
----------------
MaskRay wrote:
> delete
Done
================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.h:20
#include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/Casting.h"
----------------
MaskRay wrote:
> clang-format should move Casting.h before ErrorHandling.h
Fixed, thanks. I avoided running clang-format on this particular file since it broke custom spacing before `=` sign in `enum VariantKind` below.
================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.h:180
+
+class AArch64AuthMCExpr : public AArch64MCExpr {
+ uint16_t Discriminator;
----------------
MaskRay wrote:
>
Done
================
Comment at: llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCExpr.h:190
+public:
+ /// @name Construction
+ /// @{
----------------
MaskRay wrote:
> These annotations provide very little value. I think we discourage them for newer code to make classes more compact.
OK, got it. I added them since the surrounding code was already using them, but I agree that they do not make much sense.
================
Comment at: llvm/test/MC/AArch64/ptrauth-elf-reloc.s:1
+// RUN: split-file %s %t
+
----------------
MaskRay wrote:
> To following the convention of test naming, this probably should be `elf-reloc-ptrauth.s`
Fixed
================
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
+
----------------
MaskRay wrote:
> ditto
>
> actually, this line is so short that we should not use continuation
Fixed
================
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
----------------
MaskRay wrote:
> continuation lines are indented by 2 by convention
Fixed
================
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
----------------
MaskRay wrote:
> 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.
Applied this approach, thanks!
================
Comment at: llvm/test/MC/AArch64/ptrauth-elf-reloc.s:97
+
+// ERR1: error: expected '('
+
----------------
MaskRay wrote:
> 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 ...
> ```
It's a nice approach, fixed, thanks
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D156505/new/
https://reviews.llvm.org/D156505
More information about the llvm-commits
mailing list