Add an llvm::report_fatal_error for when the darwin kernel says we've finished an insn-step but the thread doesn't think it was insn-stepping

[jasonmolenda]

Summary

We have some failures on an arm64 CI bot where the kernel has told us that we've completed an instruction step, but when lldb checks to confirm that the thread was performing an instruction step, it is not. The debugger doesn't know how this could happen, so it stops at that point and notifies the user that there has been an anomalous occurrence (calls it an "EXC_ARM_BREAKPOINT"). Fine, but under the testsuite this will cause a testsuite failure.

This adds an llvm::report_fatal_error when not built NDEBUG if this state happens, and include two additional pieces of information in the error message to help debug what the CI bot is hitting. I'll change this to an assert without the additional information later, so it's more assertively erroring in development builds if this combination of events happens again. But I can't dynamically construct a string for an assert and have it dumped, so I'm using fatal error to debug the CI bot.

[jingham]

LGTM. Let's see if we can get this to actually trap the concurrent test failures.

lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp

case llvm::Triple::thumb:
       {
         is_actual_breakpoint = true;
         is_trace_if_actual_breakpoint_missing = true;
       }
       break;
 
     case llvm::Triple::aarch64_32:
     case llvm::Triple::aarch64: {
+      // xnu describes three things with type EXC_BREAKPOINT:
+      //
+      //   exc_code 0x102 [EXC_ARM_DA_DEBUG], exc_sub_code addr-of-insn
+      //      Watchpoint access.  exc_sub_code is the address of the
+      //      instruction which trigged the watchpoint trap.
+      //      debugserver may add the watchpoint number that was triggered
+      //      in exc_sub_sub_code.
+      //
+      //   exc_code 1 [EXC_ARM_BREAKPOINT], exc_sub_code 0
+      //      Instruction step has completed.
+      //
+      //   exc_code 1 [EXC_ARM_BREAKPOINT], exc_sub_code address-of-instruction
+      //      Software breakpoint instruction executed.
+
       if (exc_code == 1 && exc_sub_code == 0) // EXC_ARM_BREAKPOINT
       {
         // This is hit when we single instruction step aka MDSCR_EL1 SS bit 0
         // is set
-        is_actual_breakpoint = false;
+        is_actual_breakpoint = true;
         is_trace_if_actual_breakpoint_missing = true;
+#ifndef NDEBUG
+        if (thread.GetTemporaryResumeState() != eStateStepping) {
+          StreamString s;
+          s.Printf("CreateStopReasonWithMachException got EXC_BREAKPOINT [1,0] "
+                   "indicating trace event, but thread is not tracing, it has "
+                   "ResumeState %d",
+                   thread.GetTemporaryResumeState());
+          if (RegisterContextSP regctx = thread.GetRegisterContext()) {
+            if (const RegisterInfo *ri = regctx->GetRegisterInfoByName("esr")) {
+              uint32_t esr =
+                  (uint32_t)regctx->ReadRegisterAsUnsigned(ri, UINT32_MAX);
+              if (esr != UINT32_MAX) {
+                s.Printf(" esr value: 0x%" PRIx32, esr);
+              }
+            }
+          }
+          llvm::report_fatal_error(s.GetData());
+          lldbassert(
+              false &&
+              "CreateStopReasonWithMachException got EXC_BREAKPOINT [1,0] "
+              "indicating trace event, but thread was not doing a step.");
+        }
+#endif
       }
       if (exc_code == 0x102) // EXC_ARM_DA_DEBUG
       {
         // It's a watchpoint, then, if the exc_sub_code indicates a
         // known/enabled data break address from our watchpoint list.
         lldb::WatchpointSP wp_sp;
         if (target)
           wp_sp = target->GetWatchpointList().FindByAddress(