[PATCH] D158574: [AArch64][ELF] Support PAUTH ABI marking

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 5 09:48:12 PDT 2023


peter.smith added a comment.

The program properties are in the appendix as an alternative. Do we need to implement both for the same platform? If both are supported then we have the problem of what happens when one relocatable object has a notes section and the other a GNU properties section.

The ELF marking in the specification was very much a placeholder in the specification waiting for some implementation experience in prototypes. The notes section was used mostly as GNU properties are a Linux extension, and this may end up being used outside of a GNU platform. I strongly recommend choosing one or the other. Personally I would go with the note section as the properties are listed in an appendix as an alternative.

Experience from BTI has shown that assembler files, particularly those like crt0.s often creep into projects and are hard to find. Many of these assembler files will have no code pointers in them at all so giving a fatal error may be too harsh.

You may want to follow intel CET, which has a `-z cet-report = [none|warn|error]` for example `-z pauth-report = [none|warn|error]` which controls what happens when there are some objects without the note section.

I haven't checked through all the details in the implementation.



================
Comment at: llvm/tools/llvm-readobj/ELFDumper.cpp:5361
+template <class ELFT>
+static bool printARMNote(raw_ostream &OS, uint32_t NoteType,
+                         ArrayRef<uint8_t> Desc) {
----------------
I recommend printAArch64Note as ARM in all caps tends to refer to the ARM (AArch32 backend). Even if the vendor/owner name is ARM the company.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158574



More information about the llvm-commits mailing list