The current check may fail if the addition overflows. I've observed
failures of macho-invalid.test on 32-bit due to this.

Instead, compare against the remaining bytes until the end of the
object.

ErrorAsOutParameter's Error* constructor supports cases where an Error might not
be passed in (because in the calling context it's known that this call won't
fail). Most clients always have an Error present however, and for them an Error&
overload is more convenient.

It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.

S.substr(N, M) is simpler than S.slice(N, N + M).  Also, substr is
probably better recognizable than slice thanks to
std::string_view::substr.

S.substr(N) is simpler than S.slice(N, StringRef::npos) and
S.slice(N, S.size()). Also, substr is probably better recognizable
than slice thanks to std::string_view::substr.

In a mach_header, the cpusubtype is a 32-bit field, but it's split in 2
subfields:
- the low 24 bits containing the cpu subtype proper, (e.g.,
CPU_SUBTYPE_ARM64E 2)
- the high 8 bits containing a capability field used for additional
feature flags.

Notably, it's only the subtype subfield that participates in fat file
slice discrimination: the caps are ignored.

arm64e uses the caps subfield to encode a ptrauth ABI version:
- 0x80 (CPU_SUBTYPE_PTRAUTH_ABI) denotes a versioned binary
- 0x40 denotes a kernel-ABI binary
- 0x00-0x0F holds the ptrauth ABI version

This teaches the basic obj tools to decode that (or ignore it when
unneeded).

It also teaches the MachO writer to default to emitting versioned
binaries, but with a version of 0 (and without the kernel ABI flag).

Modern arm64e requires versioned binaries: a binary with 0x00 caps in
cpusubtype is now rejected by the linker and everything after. We can
live without the sophistication of specifying the version and kernel ABI
for now.

Co-authored-by: Francis Visoiu Mistrih <francisvm@apple.com>

This adds MachO support for emission of authenticated pointer
relocations.

We already support AArch64AuthMCExpr, to represent assembly expressions
such as:
  .quad <symbol>@AUTH(<key>, <discriminator> [, addr])
For example:
  .quad _g3@AUTH(ib, 1234, addr)

These @AUTH expressions lower to a new kind of MachO relocation:
  ARM64_RELOC_AUTHENTICATED_POINTER (11)

The relocation points to the referenced symbol.
The other data, describing the signing scheme and original addend
(only 32 bits instead of 64), is encoded into the addend (in the
relocated location):

  |63|62|61-51|50-49|  48  |47     -     32|31  -  0|
  | 1| 0|  0  | key | addr | discriminator | addend |

The condition was duplicated, the correct one for this message would
have been `ImportsEnd > SymbolsEnd`. However, this is a subset of
`ImportEnd > Symbols` (since `Symbols <= SymbolsEnd`), so it can be
removed altogether.

I made this thinko in 686d8ce.

Note that that change wasn't intended to be permanent, and served as a
quick stopgap to facilitate testing chained fixups in LLD before Apple
upstreamed their implementation.

Fixes #90662
Fixes #87203

The design of the export trie in macho's is that each node has a
variable length payload. When reading nodes, it should be an error if
reading the uleb128 puts you beyond the stated node size but not when
the stated size goes beyond the known part that was read.

resolves: rdar://130310832

This was primarily authored by Nick Kledzik, I added/cleaned up the test
cases.

`MachORebaseEntry::moveNext()` and `MachOBindEntry::moveNext()` assume
that the rebase/bind table ends with `{REBASE|BIND}_OPCODE_DONE` or an
actual rebase/bind. However a valid rebase/bind table might also end
with other effectively no-op opcodes, which caused the parser to move
past the end and go into the next table, resulting in corrupted entries
or infinite loops.