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

Tue Sep 24 04:53:41 PDT 2019

mstorsjo added a comment.

In D67954#1680536 <https://reviews.llvm.org/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