[Lldb-commits] [PATCH] D117559: [lldb] Remove remote testing ability from lldb**-server** tests

[Omair Javaid via lldb-commits]

On Wed, 19 Jan 2022 at 17:53, Pavel Labath via Phabricator <
reviews at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20220119/f78e7ce5/attachment.html>