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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
