[lldb-dev] Remote connection expansion?

[Mike Mestnik via lldb-dev]

On Mon, Nov 9, 2020 at 5:37 PM Greg Clayton <clayborg at gmail.com> wrote:
>
>
>
> > On Nov 4, 2020, at 1:28 PM, Mike Mestnik via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> >
> > I'm looking for support running lldb over ssh.  I can forward the
> > originating connection, but the run command is attempting to use
> > random ports on localhost to attain another connection.  This fails as
> > the localhost's are not the same.
>
> When you say you want to run lldb over ssh, do you mean run "lldb-server"
Is there really an issue with saying these are both lldb?  Seems like
my statements were unambiguous without noting a distinction.

> remotely and then have a local LLDB connect to that lldb-server?
That's the usual way lldb is used remotely, so I don't really get that
lldb does not, in some cases, mean lldb-server.

> You are looking to avoid "lldb-server" from having to bind to port 0 and then tell you which port it was actually bound to?
This is indeed a *feature* of lldb-server and not lldb, so I don't
really get your confusion when I claim lldb has a feature that's
entirely implemented with regard to lldb-server.

> >
> > Is there a platform, preferably real time, for lldb support?
> >
This is a really important question of mine!  If we can only go back
and forth on email I'd like ppl to make a best effort to lessen the
effects this has.  One tip I have, even for when ppl are chatting, is
to phrase questions in the form of an answer...  Don't ask yes/no
questions or even questions with say less than 7 answers.  Instead
provide bullet points of all the possible answers, one at a time.
There are many good reasons for everyone doing this, but here the most
relevant is to avoid round-trips that are expansive.

Can you answer your question twice?  Once If I claim that "Yes" I do
plan on having lldb choose a port to listen on and have ssh forward
that port and again for if I answer "No".

I hope you can appreciate that having ssh forward a handful of ports
for a single service is not optimal.  I'd actually do better by
writing another set of client-server applications that tunnel the IPC
over ssh...  Something I'd only do if the program was closed source.
As lldb is not, the obvious path forward is to re-implement the lldb
IPC so it's more friendly to ssh.

> > One might ask why ssh, the basic answer is I don't want to open
> > *another port on my remote host...  Even if I did I'd still have the
> > same problem, a random port would fail to connect(this time because of
> > a firewall).  The main answer is, without ssh, lldb is limited to
> > running on local or VPN networks.  I'd rather use ssh than configure a
> > VPN for this one use case.
> >
> > * lldb doesn't sound like something one would want to host, even if
> > connections were blocked from everywhere "else."
> >
> > Now I'm attempting forward error correction by guessing where this
> > topic could lead.  I would be willing to expand the network code to
> > include domain sockets, to replace the whole idea of using, IMHO
> > barbaric, port numbers.  This work could potentially include direct
> > support for ssh.  I understand that this would likely be a breaking
> > change, is there version negotiation?
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>