[LLDB] [Windows] Initial support for ARM64 register contexts

[mstorsjo]

This seems to be enough for getting a backtrace and variable values for MinGW-built binaries for ARM64.

To clarify; this is binaries that use DWARF debug info.

[labath]

Have you considered going the "native" route directly? My understanding is that this route is already functional on x86 (modulo watchpoints, which I need to get around to reviewing). It would be great to be able to delete the in-process route soon, as it's not good to have both for a long time, and for that we need to ensure that the lldb-server route does not lag behind in features. I'm not really sure what's needed to enable the lldb-server mechanism, but @aleksandr.urakov should.

One of the advantages of lldb-server is that is possible to test it by cross-debugging. The mechanism for doing that is a bit complicated, and I'm not entirely sure how that works after all the lit changes, but it goes approximately like this:

1. build lldb for the host
2. build lldb-server for the target (either on the target, or via cross-compile)
3. run lldb-server platform --server *:1234 on the target
4. run the dotest test suite arguments suitable for cross-compilation. This means:
   • setting the test compiler to be a cross compiler (cmake -DLLDB_TEST_C(XX)_COMPILER)
   • choosing a suitable test architecture (-DLLDB_TEST_ARCH)
   • telling it how to connect to the target (-DLLDB_TEST_USER_ARGS=--platform-name remote-windows --platform-url connect://remote:1234 --platform-working-dir=c:\tmp)
   • crossing your fingers :)

But, of course the easiest way to test this would be to build and test natively. The usual obstacle for that is that the arm device is too small to comfortably work on it, but you say you don't have the full build environment *yet*, so it's not clear to me whether that is the problem you're running into...

[mstorsjo]

In D67954#1680536, @labath wrote:

Have you considered going the "native" route directly? My understanding is that this route is already functional on x86 (modulo watchpoints, which I need to get around to reviewing). It would be great to be able to delete the in-process route soon, as it's not good to have both for a long time, and for that we need to ensure that the lldb-server route does not lag behind in features. I'm not really sure what's needed to enable the lldb-server mechanism, but @aleksandr.urakov should.

I haven't dug in to see what's needed to enable it (if it maybe is enabled separately per arch somewhere?) - I just built lldb for arm64, tested using it and noting that it crashed due to m_thread_reg_ctx being unset, made a first proof of concept implementation of the missing class, and noted that it actually worked for getting usable debug info from my testcase.

One of the advantages of lldb-server is that is possible to test it by cross-debugging. The mechanism for doing that is a bit complicated, and I'm not entirely sure how that works after all the lit changes, but it goes approximately like this:

1. build lldb for the host
2. build lldb-server for the target (either on the target, or via cross-compile)
3. run lldb-server platform --server *:1234 on the target
4. run the dotest test suite arguments suitable for cross-compilation. This means:
   • setting the test compiler to be a cross compiler (cmake -DLLDB_TEST_C(XX)_COMPILER)
   • choosing a suitable test architecture (-DLLDB_TEST_ARCH)
   • telling it how to connect to the target (-DLLDB_TEST_USER_ARGS=--platform-name remote-windows --platform-url connect://remote:1234 --platform-working-dir=c:\tmp)
   • crossing your fingers :)

Interesting - sounds sensible but also sounds like a bit more effort to get going than just running the usual lit tests. Will look into that at some point.

But, of course the easiest way to test this would be to build and test natively. The usual obstacle for that is that the arm device is too small to comfortably work on it, but you say you don't have the full build environment *yet*, so it's not clear to me whether that is the problem you're running into...

Well, I cross build as the environment on the target device is a bit bare, and as it's a new architecture and all, there's not much available when it comes to prebuilt packages (for everything you need for building) - I do have a working compiler on that device, but nothing else. The devices do support running i386 binaries emulated, so I could install such a version of msys2 and do building there, but even more slowly... In general as well, I think building llvm/lldb on such a device requires quite a bit of patience, and rebuilding after fetching newer upstream commits would be pretty painful as well.

I think the most practical setup, at least for lit-style tests that don't require any compilation in themselves, is cross-building all the binaries needed, moving them over to the target device, and running them with llvm-lit there. But that still requires having python available for running llvm-lit.

The alternative is probably to leverage WSL for a mess-free environment with python, shells and everything available, but I'm not sure if that messes things up (like llvm-lit thinks it runs on linux even though the binaries it should execute will run are windows ones).

[compnerd]

Honestly, this is just setting up the register context for ARM64. I dont think that there is much of a test for this. I mean, I suppose you could test this by instantiating the context and trying to read it through the interface. But, I question the value of such a test. Whether you go with the in-process or out-of-process approach and whether you are doing DWARF of CodeView debugging this is going to be needed. As to running the test suite - you can cross-compile and run the tests remotely.

lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.cpp

57

It formats better if you add a trailing comma to the list (gpr_cpsr,)

64

Similar

70

Similar

[labath]

In D67954#1680893, @compnerd wrote:

Honestly, this is just setting up the register context for ARM64. I dont think that there is much of a test for this. I mean, I suppose you could test this by instantiating the context and trying to read it through the interface. But, I question the value of such a test. Whether you go with the in-process or out-of-process approach and whether you are doing DWARF of CodeView debugging this is going to be needed. As to running the test suite - you can cross-compile and run the tests remotely.

I disagree. As D67892 shows, it quite possible to mess up even with a "trivial" class as this one. Ideally I'd like to see here tests similar to what @mgorny added for x86 (see lldb/lit/Register). However, the problem is that we don't have a way to run those tests at the moment. Since this is a problem that's going to show up sooner or later, perhaps with more "nontrivial" patches, I think it's good to figure out what to do early.

[aleksandr.urakov]

In D67954#1680536, @labath wrote:

Have you considered going the "native" route directly? My understanding is that this route is already functional on x86 (modulo watchpoints, which I need to get around to reviewing). It would be great to be able to delete the in-process route soon, as it's not good to have both for a long time, and for that we need to ensure that the lldb-server route does not lag behind in features. I'm not really sure what's needed to enable the lldb-server mechanism, but @aleksandr.urakov should.

Hello! I'm just commenting out content of the ProcessWindows::Initialize() function to use the lldb-server route.

There are several problems with cross-debugging on Windows now, @leonid.mashinskiy got deep into this. Leonid, can you explain the difficulties, please?

[mstorsjo]

Added two lit/shell based tests that pass on both linux/arm64 and windows/arm64. I've managed to set up some sort of hacked up environment where I can run lit/shell based tests (even though the main python test driver runs in WSL, but executing native windows binaries for the tests).

I also added a NativeRegisterContext for arm64, for lldb-server. For the RegisterInfoInterface for NativeRegisterContext, I reused RegisterInfoPOSIX_arm64 instead of creating a new copy similar to it, since I didn't really see anything OS specific in there.

The tests pass both with and without use of lldb-server. However, when using lldb-server with NativeRegisterContext, while the register values are correct, I don't get a correct working backtrace with it. Without lldb-server, I get a perfect backtrace. (The tested binary uses SEH unwind tables, but DWARF debug info.) Any clues about what might be going wrong there?

[labath]

Thank you _very_ much for those tests. +@mgorny, in case he has any comments on those.

In D67954#1707292, @mstorsjo wrote:

The tests pass both with and without use of lldb-server. However, when using lldb-server with NativeRegisterContext, while the register values are correct, I don't get a correct working backtrace with it. Without lldb-server, I get a perfect backtrace. (The tested binary uses SEH unwind tables, but DWARF debug info.) Any clues about what might be going wrong there?

Hard to say off-hand, but the first thing I'd check is whether the information about loaded modules and their addresses is making its way into lldb. You can use the "image list" command to inspect that. Then there's the "image show-unwind" command which can show you how lldb will try to unwind for a given function/address. Also, if you enable the "unwind" log channel (log enable lldb unwind), you'll get a trace of what lldb did while attempting to unwind.

[mstorsjo]

In D67954#1707791, @labath wrote:

Thank you _very_ much for those tests. +@mgorny, in case he has any comments on those.

In D67954#1707292, @mstorsjo wrote:

The tests pass both with and without use of lldb-server. However, when using lldb-server with NativeRegisterContext, while the register values are correct, I don't get a correct working backtrace with it. Without lldb-server, I get a perfect backtrace. (The tested binary uses SEH unwind tables, but DWARF debug info.) Any clues about what might be going wrong there?

Hard to say off-hand, but the first thing I'd check is whether the information about loaded modules and their addresses is making its way into lldb. You can use the "image list" command to inspect that. Then there's the "image show-unwind" command which can show you how lldb will try to unwind for a given function/address. Also, if you enable the "unwind" log channel (log enable lldb unwind), you'll get a trace of what lldb did while attempting to unwind.

Thanks for the debugging tips. When I run image list I get error: the target has no associated executable images, so that pretty clearly shows that something's missing. On x86_64, image list shows only the debugged exe itself, when run with LLDB_USE_LLDB_SERVER=1, while it shows the exe and a few system dlls (ntdll, kernel32, kernelbase and ucrtbase) when run without lldb-server.

[mstorsjo]

In D67954#1707791, @labath wrote:

Hard to say off-hand, but the first thing I'd check is whether the information about loaded modules and their addresses is making its way into lldb. You can use the "image list" command to inspect that. Then there's the "image show-unwind" command which can show you how lldb will try to unwind for a given function/address. Also, if you enable the "unwind" log channel (log enable lldb unwind), you'll get a trace of what lldb did while attempting to unwind.

Thanks for the debugging pointers. I managed to track this down, with a fix suggestion in D68939. I guess that indicates another issue elsewhere, but it's pretty much out of scope for me to dig further into that issue now. I guess it should be possible to reproduce the same issue on x86_64 by changing the triple similarly there as well.

[mgorny]

Is there a specific reason you've only covered x0..x7 in the test?

[mstorsjo]

In D67954#2515028, @mgorny wrote:

Is there a specific reason you've only covered x0..x7 in the test?

No, only for keeping the test short and cohesive.

lldb/source/Plugins/Process/Windows/Common/CMakeLists.txt

 
 add_lldb_library(lldbPluginProcessWindowsCommon PLUGIN
   DebuggerThread.cpp
   LocalDebugDelegate.cpp
   NativeProcessWindows.cpp
   NativeRegisterContextWindows.cpp
   NativeRegisterContextWindows_i386.cpp
   NativeRegisterContextWindows_WoW64.cpp
   NativeRegisterContextWindows_x86_64.cpp
   NativeThreadWindows.cpp
   ProcessDebugger.cpp
   ProcessWindows.cpp
   ProcessWindowsLog.cpp
   RegisterContextWindows.cpp
   TargetThreadWindows.cpp
+  arm64/RegisterContextWindows_arm64.cpp
   x64/RegisterContextWindows_x64.cpp
   x86/RegisterContextWindows_x86.cpp
-  # TODO add support for ARM (NT) and ARM64
+  # TODO add support for ARM (NT)
 
   LINK_LIBS
     lldbCore
     lldbHost
     lldbInterpreter
     lldbPluginDynamicLoaderWindowsDYLD
     lldbSymbol
     lldbTarget
     ws2_32
     rpcrt4
   LINK_COMPONENTS
     Support
   )

lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp

 #include "lldb/Utility/Logging.h"
 #include "lldb/Utility/State.h"
 
 #include "Plugins/Process/Utility/UnwindLLDB.h"
 #include "ProcessWindows.h"
 #include "ProcessWindowsLog.h"
 #include "TargetThreadWindows.h"
 
-// TODO support _M_ARM and _M_ARM64
+// TODO support _M_ARM
 #if defined(__x86_64__) || defined(_M_AMD64)
 #include "x64/RegisterContextWindows_x64.h"
 #elif defined(__i386__) || defined(_M_IX86)
 #include "x86/RegisterContextWindows_x86.h"
+#elif defined(__aarch64__) || defined(_M_ARM64)
+#include "arm64/RegisterContextWindows_arm64.h"
 #endif
 
 using namespace lldb;
 using namespace lldb_private;
 
 TargetThreadWindows::TargetThreadWindows(ProcessWindows &process,
                                          const HostThread &thread)
     : Thread(process, thread.GetNativeThread().GetThreadId()),
if (!m_thread_reg_ctx_sp) {
       ArchSpec arch = HostInfo::GetArchitecture();
       switch (arch.GetMachine()) {
       case llvm::Triple::arm:
       case llvm::Triple::thumb:
         LLDB_LOG(log, "debugging ARM (NT) targets is currently unsupported");
         break;
 
       case llvm::Triple::aarch64:
-        LLDB_LOG(log, "debugging ARM64 targets is currently unsupported");
+#if defined(__aarch64__) || defined(_M_ARM64)
+        m_thread_reg_ctx_sp.reset(
+            new RegisterContextWindows_arm64(*this, concrete_frame_idx));
+#else
+        LLDB_LOG(log, "debugging foreign targets is currently unsupported");
+#endif
         break;
 
       case llvm::Triple::x86:
 #if defined(__i386__) || defined(_M_IX86)
         m_thread_reg_ctx_sp.reset(
             new RegisterContextWindows_x86(*this, concrete_frame_idx));
 #else
         LLDB_LOG(log, "debugging foreign targets is currently unsupported");

lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.h

+//===-- RegisterContextWindows_arm64.h --------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef liblldb_RegisterContextWindows_arm64_H_
+#define liblldb_RegisterContextWindows_arm64_H_
+
+#if defined(__aarch64__) || defined(_M_ARM64)
+
+#include "RegisterContextWindows.h"
+#include "lldb/lldb-forward.h"
+
+namespace lldb_private {
+
+class Thread;
+
+class RegisterContextWindows_arm64 : public RegisterContextWindows {
+public:
+  // Constructors and Destructors
+  RegisterContextWindows_arm64(Thread &thread, uint32_t concrete_frame_idx);
+
+  virtual ~RegisterContextWindows_arm64();
+
+  // Subclasses must override these functions
+  size_t GetRegisterCount() override;
+
+  const RegisterInfo *GetRegisterInfoAtIndex(size_t reg) override;
+
+  size_t GetRegisterSetCount() override;
+
+  const RegisterSet *GetRegisterSet(size_t reg_set) override;
+
+  bool ReadRegister(const RegisterInfo *reg_info,
+                    RegisterValue &reg_value) override;
+
+  bool WriteRegister(const RegisterInfo *reg_info,
+                     const RegisterValue &reg_value) override;
+};
+} // namespace lldb_private
+
+#endif // defined(__aarch64__) || defined(_M_ARM64)
+
+#endif // #ifndef liblldb_RegisterContextWindows_arm64_H_

lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.cpp

+//===-- RegisterContextWindows_arm64.cpp ------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#if defined(__aarch64__) || defined(_M_ARM64)
+
+#include "lldb/Host/windows/HostThreadWindows.h"
+#include "lldb/Host/windows/windows.h"
+#include "lldb/Utility/RegisterValue.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/lldb-private-types.h"
+
+#include "RegisterContextWindows_arm64.h"
+#include "TargetThreadWindows.h"
+
+#include "llvm/ADT/STLExtras.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+#define GPR_OFFSET(idx) 0
+#define GPR_OFFSET_NAME(reg) 0
+
+#define FPU_OFFSET(idx) 0
+#define FPU_OFFSET_NAME(reg) 0
+
+#define EXC_OFFSET_NAME(reg) 0
+#define DBG_OFFSET_NAME(reg) 0
+
+#define DEFINE_DBG(reg, i)                                                     \
+  #reg, NULL,                                                                  \
+      0, DBG_OFFSET_NAME(reg[i]), eEncodingUint, eFormatHex,                   \
+                              {LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM,       \
+                               LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM,       \
+                               LLDB_INVALID_REGNUM },                          \
+                               NULL, NULL, NULL, 0
+
+// Include RegisterInfos_arm64 to declare our g_register_infos_arm64 structure.
+#define DECLARE_REGISTER_INFOS_ARM64_STRUCT
+#include "Plugins/Process/Utility/RegisterInfos_arm64.h"
+#undef DECLARE_REGISTER_INFOS_ARM64_STRUCT
+
+static size_t k_num_register_infos =
+    llvm::array_lengthof(g_register_infos_arm64_le);
+
+// Array of lldb register numbers used to define the set of all General Purpose
+// Registers
+uint32_t g_gpr_reg_indices[] = {
+    gpr_x0,  gpr_x1,  gpr_x2,  gpr_x3,  gpr_x4,  gpr_x5,  gpr_x6,
+    gpr_x7,  gpr_x8,  gpr_x9,  gpr_x10, gpr_x11, gpr_x12, gpr_x13,
+    gpr_x14, gpr_x15, gpr_x16, gpr_x17, gpr_x18, gpr_x19, gpr_x20,
+    gpr_x21, gpr_x22, gpr_x23, gpr_x24, gpr_x25, gpr_x26, gpr_x27,
+    gpr_x28, gpr_fp,  gpr_lr,  gpr_sp,  gpr_pc,  gpr_cpsr};
+
+uint32_t g_fpu_reg_indices[] = {
+    fpu_v0,  fpu_v1,  fpu_v2,  fpu_v3,  fpu_v4,   fpu_v5,  fpu_v6,
+    fpu_v7,  fpu_v8,  fpu_v9,  fpu_v10, fpu_v11,  fpu_v12, fpu_v13,
+    fpu_v14, fpu_v15, fpu_v16, fpu_v17, fpu_v18,  fpu_v19, fpu_v20,
+    fpu_v21, fpu_v22, fpu_v23, fpu_v24, fpu_v25,  fpu_v26, fpu_v27,
+    fpu_v28, fpu_v29, fpu_v30, fpu_v31, fpu_fpsr, fpu_fpcr};
+
+RegisterSet g_register_sets[] = {
+    {"General Purpose Registers", "gpr",
+     llvm::array_lengthof(g_gpr_reg_indices), g_gpr_reg_indices},
+    {"Floating Point Registers", "fpu",
+     llvm::array_lengthof(g_fpu_reg_indices), g_fpu_reg_indices}};
+
+// Constructors and Destructors
+RegisterContextWindows_arm64::RegisterContextWindows_arm64(
+    Thread &thread, uint32_t concrete_frame_idx)
+    : RegisterContextWindows(thread, concrete_frame_idx) {}
+
+RegisterContextWindows_arm64::~RegisterContextWindows_arm64() {}
+
+size_t RegisterContextWindows_arm64::GetRegisterCount() {
+  return llvm::array_lengthof(g_register_infos_arm64_le);
+}
+
+const RegisterInfo *
+RegisterContextWindows_arm64::GetRegisterInfoAtIndex(size_t reg) {
+  if (reg < k_num_register_infos)
+    return &g_register_infos_arm64_le[reg];
+  return NULL;
+}
+
+size_t RegisterContextWindows_arm64::GetRegisterSetCount() {
+  return llvm::array_lengthof(g_register_sets);
+}
+
+const RegisterSet *
+RegisterContextWindows_arm64::GetRegisterSet(size_t reg_set) {
+  return &g_register_sets[reg_set];
+}
+
+bool RegisterContextWindows_arm64::ReadRegister(const RegisterInfo *reg_info,
+                                                RegisterValue &reg_value) {
+  if (!CacheAllRegisterValues())
+    return false;
+
+  if (reg_info == nullptr)
+    return false;
+
+  const uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
+
+  switch (reg) {
+  case gpr_x0:
+  case gpr_x1:
+  case gpr_x2:
+  case gpr_x3:
+  case gpr_x4:
+  case gpr_x5:
+  case gpr_x6:
+  case gpr_x7:
+  case gpr_x8:
+  case gpr_x9:
+  case gpr_x10:
+  case gpr_x11:
+  case gpr_x12:
+  case gpr_x13:
+  case gpr_x14:
+  case gpr_x15:
+  case gpr_x16:
+  case gpr_x17:
+  case gpr_x18:
+  case gpr_x19:
+  case gpr_x20:
+  case gpr_x21:
+  case gpr_x22:
+  case gpr_x23:
+  case gpr_x24:
+  case gpr_x25:
+  case gpr_x26:
+  case gpr_x27:
+  case gpr_x28:
+    reg_value.SetUInt64(m_context.X[reg - gpr_x0]);
+    break;
+
+  case gpr_fp:
+    reg_value.SetUInt64(m_context.Fp);
+    break;
+  case gpr_sp:
+    reg_value.SetUInt64(m_context.Sp);
+    break;
+  case gpr_lr:
+    reg_value.SetUInt64(m_context.Lr);
+    break;
+  case gpr_pc:
+    reg_value.SetUInt64(m_context.Pc);
+    break;
+  case gpr_cpsr:
+    reg_value.SetUInt64(m_context.Cpsr);
+    break;
+
+  case gpr_w0:
+  case gpr_w1:
+  case gpr_w2:
+  case gpr_w3:
+  case gpr_w4:
+  case gpr_w5:
+  case gpr_w6:
+  case gpr_w7:
+  case gpr_w8:
+  case gpr_w9:
+  case gpr_w10:
+  case gpr_w11:
+  case gpr_w12:
+  case gpr_w13:
+  case gpr_w14:
+  case gpr_w15:
+  case gpr_w16:
+  case gpr_w17:
+  case gpr_w18:
+  case gpr_w19:
+  case gpr_w20:
+  case gpr_w21:
+  case gpr_w22:
+  case gpr_w23:
+  case gpr_w24:
+  case gpr_w25:
+  case gpr_w26:
+  case gpr_w27:
+  case gpr_w28:
+    reg_value.SetUInt32(
+        static_cast<uint32_t>(m_context.X[reg - gpr_x0] & 0xffffffff));
+    break;
+
+  case fpu_v0:
+  case fpu_v1:
+  case fpu_v2:
+  case fpu_v3:
+  case fpu_v4:
+  case fpu_v5:
+  case fpu_v6:
+  case fpu_v7:
+  case fpu_v8:
+  case fpu_v9:
+  case fpu_v10:
+  case fpu_v11:
+  case fpu_v12:
+  case fpu_v13:
+  case fpu_v14:
+  case fpu_v15:
+  case fpu_v16:
+  case fpu_v17:
+  case fpu_v18:
+  case fpu_v19:
+  case fpu_v20:
+  case fpu_v21:
+  case fpu_v22:
+  case fpu_v23:
+  case fpu_v24:
+  case fpu_v25:
+  case fpu_v26:
+  case fpu_v27:
+  case fpu_v28:
+  case fpu_v29:
+  case fpu_v30:
+  case fpu_v31:
+    reg_value.SetBytes(m_context.V[reg - fpu_v0].B, reg_info->byte_size,
+                       endian::InlHostByteOrder());
+    break;
+
+  case fpu_s0:
+  case fpu_s1:
+  case fpu_s2:
+  case fpu_s3:
+  case fpu_s4:
+  case fpu_s5:
+  case fpu_s6:
+  case fpu_s7:
+  case fpu_s8:
+  case fpu_s9:
+  case fpu_s10:
+  case fpu_s11:
+  case fpu_s12:
+  case fpu_s13:
+  case fpu_s14:
+  case fpu_s15:
+  case fpu_s16:
+  case fpu_s17:
+  case fpu_s18:
+  case fpu_s19:
+  case fpu_s20:
+  case fpu_s21:
+  case fpu_s22:
+  case fpu_s23:
+  case fpu_s24:
+  case fpu_s25:
+  case fpu_s26:
+  case fpu_s27:
+  case fpu_s28:
+  case fpu_s29:
+  case fpu_s30:
+  case fpu_s31:
+    reg_value.SetFloat(m_context.V[reg - fpu_s0].S[0]);
+    break;
+
+  case fpu_d0:
+  case fpu_d1:
+  case fpu_d2:
+  case fpu_d3:
+  case fpu_d4:
+  case fpu_d5:
+  case fpu_d6:
+  case fpu_d7:
+  case fpu_d8:
+  case fpu_d9:
+  case fpu_d10:
+  case fpu_d11:
+  case fpu_d12:
+  case fpu_d13:
+  case fpu_d14:
+  case fpu_d15:
+  case fpu_d16:
+  case fpu_d17:
+  case fpu_d18:
+  case fpu_d19:
+  case fpu_d20:
+  case fpu_d21:
+  case fpu_d22:
+  case fpu_d23:
+  case fpu_d24:
+  case fpu_d25:
+  case fpu_d26:
+  case fpu_d27:
+  case fpu_d28:
+  case fpu_d29:
+  case fpu_d30:
+  case fpu_d31:
+    reg_value.SetDouble(m_context.V[reg - fpu_d0].D[0]);
+    break;
+
+  case fpu_fpsr:
+    reg_value.SetUInt32(m_context.Fpsr);
+    break;
+
+  case fpu_fpcr:
+    reg_value.SetUInt32(m_context.Fpcr);
+    break;
+
+  default:
+    reg_value.SetValueToInvalid();
+    return false;
+  }
+  return true;
+}
+
+bool RegisterContextWindows_arm64::WriteRegister(
+    const RegisterInfo *reg_info, const RegisterValue &reg_value) {
+  // Since we cannot only write a single register value to the inferior, we
+  // need to make sure our cached copy of the register values are fresh.
+  // Otherwise when writing EAX, for example, we may also overwrite some other
+  // register with a stale value.
+  if (!CacheAllRegisterValues())
+    return false;
+
+  const uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
+
+  switch (reg) {
+  case gpr_x0:
+  case gpr_x1:
+  case gpr_x2:
+  case gpr_x3:
+  case gpr_x4:
+  case gpr_x5:
+  case gpr_x6:
+  case gpr_x7:
+  case gpr_x8:
+  case gpr_x9:
+  case gpr_x10:
+  case gpr_x11:
+  case gpr_x12:
+  case gpr_x13:
+  case gpr_x14:
+  case gpr_x15:
+  case gpr_x16:
+  case gpr_x17:
+  case gpr_x18:
+  case gpr_x19:
+  case gpr_x20:
+  case gpr_x21:
+  case gpr_x22:
+  case gpr_x23:
+  case gpr_x24:
+  case gpr_x25:
+  case gpr_x26:
+  case gpr_x27:
+  case gpr_x28:
+    m_context.X[reg - gpr_x0] = reg_value.GetAsUInt64();
+    break;
+
+  case gpr_fp:
+    m_context.Fp = reg_value.GetAsUInt64();
+    break;
+  case gpr_sp:
+    m_context.Sp = reg_value.GetAsUInt64();
+    break;
+  case gpr_lr:
+    m_context.Lr = reg_value.GetAsUInt64();
+    break;
+  case gpr_pc:
+    m_context.Pc = reg_value.GetAsUInt64();
+    break;
+  case gpr_cpsr:
+    m_context.Cpsr = reg_value.GetAsUInt64();
+    break;
+
+  case fpu_v0:
+  case fpu_v1:
+  case fpu_v2:
+  case fpu_v3:
+  case fpu_v4:
+  case fpu_v5:
+  case fpu_v6:
+  case fpu_v7:
+  case fpu_v8:
+  case fpu_v9:
+  case fpu_v10:
+  case fpu_v11:
+  case fpu_v12:
+  case fpu_v13:
+  case fpu_v14:
+  case fpu_v15:
+  case fpu_v16:
+  case fpu_v17:
+  case fpu_v18:
+  case fpu_v19:
+  case fpu_v20:
+  case fpu_v21:
+  case fpu_v22:
+  case fpu_v23:
+  case fpu_v24:
+  case fpu_v25:
+  case fpu_v26:
+  case fpu_v27:
+  case fpu_v28:
+  case fpu_v29:
+  case fpu_v30:
+  case fpu_v31:
+    memcpy(m_context.V[reg - fpu_v0].B, reg_value.GetBytes(), 16);
+    break;
+
+  case fpu_fpsr:
+    m_context.Fpsr = reg_value.GetAsUInt32();
+    break;
+
+  case fpu_fpcr:
+    m_context.Fpcr = reg_value.GetAsUInt32();
+    break;
+
+  default:
+    return false;
+  }
+
+  // Physically update the registers in the target process.
+  return ApplyAllRegisterValues();
+}
+
+#endif // defined(__aarch64__) || defined(_M_ARM64)