[lldb-dev] Remote connection expansion?
Pavel Labath via lldb-dev
lldb-dev at lists.llvm.org
Wed Nov 18 06:07:16 PST 2020
On 11/11/2020 20:11, Mike Mestnik via lldb-dev wrote:
> 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.
"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
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
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.
More information about the lldb-dev