[lld] [lld][AArch64][ELF][PAC] Support AUTH relocations and AUTH ELF marking (PR #72714)

Daniil Kovalev via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 19 08:09:09 PDT 2024


kovdan01 wrote:

@MaskRay Thanks for your feedback, please see new version of the changes. Overall comment:

- The PR is now dependent on https://github.com/llvm/llvm-project/pull/85231, so buildkite job fails expectedly.
- Only keep support for GNU property, drop support for the alternative.
- Avoid mixing different terms in comments: applied your suggestions with minor typo fixes d32b8e32fc1c938e5a005997b832d215a308037d + inspected other comments and fixed them as well 4409838992a87a325843393be1ff30c67cdabc7b
- With new version of spec, the size of the core info becomes exactly 16 bytes. Do we want to use a fixed-size container `std::optional<std::array<uint8_t, 16>>` (sizeof 17, alignof 1, optional for a case of no core info) instead of `ArrayRef<uint8_t>` (sizeof 16, alignof 8)?
- Renamed "AArch64 PAuth ABI tag" to and "AArch64 PAuth ABI compatibility info" to "AArch64 PAuth ABI core info" (728c93355150ef5ad712aca3910def600d68ee86, 128831c02cb54ed7b0b9afa7c17b3f8d3ffb6f7c) as defined in new version of the spec.
- `Twine::utohexstr` instead of `toHex` with `/*LowerCase=*/true` - I use the latter since I want to print an `ArrayRef` of 16 bytes, not a single `uint64_t`. We can probably print it as two bytes, but I'm not sure if it would be nice and if it would not cause issues with different endianness. Do I miss something?


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


More information about the llvm-commits mailing list