On Mon, Nov 9, 2020 at 5:37 PM Greg Clayton <clayb...@gmail.com> wrote: > > > > > On Nov 4, 2020, at 1:28 PM, Mike Mestnik via lldb-dev > > <lldb-dev@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@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev