Generating __debugbreak() for TRAP_SEQUENCE1_ on Windows ARM64

The instruction 'BRK #F000' does trap on Windows ARM64 which is different from
other ARM64 platforms. Calling __debugbreak() which will produce the right
encoding and always supported by MSVC and clang.

Bug: 893460
Change-Id: I54e2d8de6ae7d9ba5929dc8e382e18a99d5aaeb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1879677Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Tom Tan <Tom.Tan@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#710700}

base/immediate_crash.h

@@ -99,7 +99,9 @@
 
 #elif defined(ARCH_CPU_ARM64)
 
-#define TRAP_SEQUENCE1_() __asm volatile("brk #0\n")
+// Windows ARM64 uses "BRK #F000" as its breakpoint instruction, and
+// __debugbreak() generates that in both VC++ and clang.
+#define TRAP_SEQUENCE1_() __debugbreak()
 // Intentionally empty: __builtin_unreachable() is always part of the sequence
 // (see IMMEDIATE_CRASH below) and already emits a ud2 on Win64,
 // https://crbug.com/958373

base/immediate_crash_unittest.cc

@@ -143,10 +143,22 @@ TEST(ImmediateCrashTest, ExpectedOpcodeSequence) {
 
   // Look for two IMMEDIATE_CRASH() opcode sequences.
   for (int i = 0; i < 2; ++i) {
+
+#if defined(OS_WIN)
+
+    // BRK #F000
+    EXPECT_EQ(0XD43E0000, *++it);
+    // BRK #1
+    EXPECT_EQ(0XD4200020, *++it);
+
+#else
+
     // BRK #0
     EXPECT_EQ(0XD4200000, *++it);
     // HLT #0
     EXPECT_EQ(0xD4400000, *++it);
+
+#endif  //  defined(OS_WIN)
   }
 
 #endif  // defined(ARCH_CPU_X86_FAMILY)