[lldb-dev] Remote connection expansion?
Mike Mestnik via lldb-dev
lldb-dev at lists.llvm.org
Wed Nov 11 11:11:28 PST 2020
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
More information about the lldb-dev