labath added a comment. In D117559#3254095 <https://reviews.llvm.org/D117559#3254095>, @DavidSpickett wrote:
> I'm running > `lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py`. > > If the details matter any... > > In qemu: > > $ ./build-cross/bin/lldb-server platform --server --listen 0.0.0.0:54321 > > On the host: > > $ ./bin/lldb-dotest --platform-name remote-linux --platform-url > connect://<VM IP>:54321 --platform-working-dir /tmp/test_lldb -p > TestGdbRemoteMemoryTagging.py --arch aarch64 Got it. Thanks. > I have qemu setup so that any port lldb-server picks should be accessible > from the host and the VM is just running the usual background linux stuff > plus lldb-server. Not a lot to use up ports. The tricky part is that even individual parallel test runs (if you run the whole test suite, not just a single test like you did above) can race with each other. > Can you remind me what forward/reverse mean here? I guess that forward is us > telling the remote the port to use, which might already be taken on the > remote itself. Correct. > Then reverse is the remote launching the lldb-server on a port it chooses, > then telling us what it chose. Not quite. In "reverse mode" it is the client (in this case -- the test suite) who is choosing a port and listening on it. lldb-server gets an address and it connects to it. We also have the method which you described (we probably have more connection methods than we should). That one is also reliable (though it gets fuzzy with IPv6, as then the port number alone does not uniquely identify an endpoint), but it has more moving parts, and it is not implemented in the test suite -- just in the client, which we don't use for these tests. One of the goals I am trying to achieve here is actually to be able to test the various connection methods at the lldb-server level, but for that I need to untangle the connection code from the rest of the test suite setup. And ideally I would only support one method (the simplest one) for the remote connections and have mark other tests `@skipIfRemote` -- the reason for that is that we'd need different code to (e.g.) read the server-selected port from a remote machine than we would for the local one, so this would be more of a test of the test suite than the server itself. In D117559#3254148 <https://reviews.llvm.org/D117559#3254148>, @omjavaid wrote: > This doesnt interfere with LLDB tests for SVE. Rather I have not used it in a > while for SVE tests I ahve using setup similar to to one David has explained > above. If you're using the setup that David mentioned, then this would break that. I am going to try to make a patch to use reverse connect for these tests instead. > @labath Do you know if android adb based tests are being run anywhere? Are we > still maintaining this support and does it work? I would guess "no", but I don't know, really. I created this patch to find that out myself. :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D117559/new/ https://reviews.llvm.org/D117559 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
