[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 debugging

[Aleksandr Urakov via Phabricator via lldb-commits]

aleksandr.urakov added a subscriber: leonid.mashinskiy.
aleksandr.urakov added a comment.

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?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67954/new/

https://reviews.llvm.org/D67954



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 debugging

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

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.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67954/new/

https://reviews.llvm.org/D67954



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 debugging

[Saleem Abdulrasool via Phabricator via lldb-commits]

compnerd accepted this revision.
compnerd added a comment.
This revision is now accepted and ready to land.

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.




Comment at: 
lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.cpp:57
+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};
+

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



Comment at: 
lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.cpp:64
+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};
+

Similar



Comment at: 
lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.cpp:70
+{"Floating Point Registers", "fpu",
+ llvm::array_lengthof(g_fpu_reg_indices), g_fpu_reg_indices}};
+

Similar


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67954/new/

https://reviews.llvm.org/D67954



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 debugging

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo added a comment.

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).


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67954/new/

https://reviews.llvm.org/D67954



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 debugging

[Pavel Labath via Phabricator via lldb-commits]

labath added a subscriber: aleksandr.urakov.
labath added a comment.

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...


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67954/new/

https://reviews.llvm.org/D67954



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 debugging

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo added a comment.

> 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.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67954/new/

https://reviews.llvm.org/D67954



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 debugging

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo created this revision.
mstorsjo added reviewers: labath, compnerd, amccarth, hhb, asmith.
Herald added subscribers: JDevlieghere, abidh, kristof.beyls, mgorny.
Herald added a project: LLDB.

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

This doesn't implement the intended future setup (if I understand things 
correctly) of using NativeRegisterContexts.

What's a suitable testcase for this? So far I've just built LLDB and tested 
debugging a real binary with it. I don't have the full llvm build environment 
available on the arm64 windows machine yet, so running the full testsuite isn't 
really easily feasible. (Perhaps it would be doable via WSL?)


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D67954

Files:
  lldb/source/Plugins/Process/Windows/Common/CMakeLists.txt
  lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp
  
lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.cpp
  
lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.h

Index: lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.h
@@ -0,0 +1,47 @@
+//===-- 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 , 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 _value) override;
+
+  bool WriteRegister(const RegisterInfo *reg_info,
+ const RegisterValue _value) override;
+};
+} // namespace lldb_private
+
+#endif // defined(__aarch64__) || defined(_M_ARM64)
+
+#endif // #ifndef liblldb_RegisterContextWindows_arm64_H_
Index: lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.cpp
===
--- /dev/null
+++ lldb/source/Plugins/Process/Windows/Common/arm64/RegisterContextWindows_arm64.cpp
@@ -0,0 +1,423 @@
+//===-- 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 =
+