On 11/11/2020 20:11, Mike Mestnik via lldb-dev wrote:
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.
"Remote debugging" can mean different things to different people. Please
assume good faith. I'm sure Greg asked this question because he was
genuinely not sure what you meant, and not just to annoy you.
As lldb is not, the obvious path forward is to re-implement the lldb
IPC so it's more friendly to ssh.
I've been wanting to do something like that for a while, since the
current design has a very 1970 (the decade FTP was invented) feel to it.
However, the issue never came up on the projects that I worked on, so I
couldn't find time to do that.
The way this currently works is that lldb sends a packet like
"qSpawnGdbServer", which causes lldb-server platform to spawn a gdb
server (either lldb-server gdbserver, or debugserver) and return the
port number it is listening on. One way to change that would be to have
lldb open *another* connection to the same lldb-server, and then issue
something like "qExecGdbserver" (a new command). This command would
cause the platform to exec (without forking) the debug server and pass
the already established connection to it (something which we already
support).
Then there would be no need for two ports, as both connections would be
established through the same one.
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?
Direct support for ssh might be interesting as well, though I am not
sure what exactly would that mean. As for version negotiation, the way
that's generally handled is by making a new gdb-remote packet or a
"feature" (see
https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#qSupported)
and then checking for that.
So, for example, in order to implement my idea, we could have the
lldb-server platform send qSpawnGdbServer+ in its qSupported response,
and then have lldb key off of that.
cheers,
pavel
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
