[Lldb-commits] [PATCH] D67954: [LLDB] [Windows] Initial support for ARM64 debugging
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue Sep 24 04:38:42 PDT 2019
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...
CHANGES SINCE LAST ACTION
More information about the lldb-commits