[llvm] [BOLT][AArch64] Handle OpNegateRAState to enable optimizing binaries with pac-ret hardening (PR #120064)

[Gergely Bálint via llvm-commits]

================
@@ -2769,10 +2770,12 @@ struct CFISnapshot {
       llvm_unreachable("unsupported CFI opcode");
       break;
     case MCCFIInstruction::OpNegateRAState:
-      if (!(opts::BinaryAnalysisMode || opts::HeatmapMode)) {
-        llvm_unreachable("BOLT-ERROR: binaries using pac-ret hardening (e.g. "
-                         "as produced by '-mbranch-protection=pac-ret') are "
-                         "currently not supported by BOLT.");
+      if (!(opts::BinaryAnalysisMode || opts::HeatmapMode ||
+            opts::AllowPacret)) {
+        llvm_unreachable(
+            "BOLT-ERROR: support for binaries using pac-ret hardening (e.g. as "
+            "produced by '-mbranch-protection=pac-ret') is experimental\n"
+            "BOLT-ERROR: set --allow-experimental-pacret to allow processing");
----------------
bgergely0 wrote:

To not fail on binaries compiled with `-mbranch-protection=none` but on a system where the C runtime objects (e.g. `crtbegin.o`) were compiled with `pac-ret`, we cannot check for all `.cfi_negate_ra_state`. Doing so would also break a lot of unittests on the aarch64 runner.

We have two options:
- find all C runtime function names (including function names from different libc implementations), and ignore `.cfi_negate_ra_state`s in them OR
- move the check later (in time) to the point where processing CFIs previously crashed for OpNegateRAState. 

I've implemented the second option here, so that explains why there is no crash for the unittests. Only those binaries crash where at least one function triggers `unwindCFIState`. This approach is a bit "probabilistic", the other could be more robust, but that requires manual check for function names.

This illustrates that adding the `--allow-experimental-pacret` flag introduces extra complexity which we would not have without it. 

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