[lldb-dev] Remote connection expansion?

[Pavel Labath via lldb-dev]

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 
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