On Wed, 19 Jan 2022 at 17:53, Pavel Labath via Phabricator < revi...@reviews.llvm.org> wrote:
> 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. > The current set of changes at least dont hurt. I actually tried a test run with your patch applied before responding. > > > @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
