Delve: Long-running debug server

[hrobertson]

This is a feature request/discussion.

Current Usage

To perform remote debugging I need to start a debug session on the remote machine, eg.

$ dlv exec mypackage --headless --listen=10.0.0.1:1234
API server listening at: 10.0.0.1:1234

Then from my client I can connect to that session.

$ dlv connect 10.0.0.1:8181
Type 'help' for list of commands.
(dlv) q

Then if I want to debug again I need to go back to my remote machine and restart the server.

^C
$ dlv exec mypackage --headless --listen=10.0.0.1:1234
API server listening at: 10.0.0.1:1234

Proposed Usage

I propose that it should be possible to start a long running delve server that will itself start debug sessions on behalf of clients:

$ dlv server --listen=10.0.0.1:1234 --password="password"
API server listening at: 10.0.0.1:1234

And then from my client machine:

$ dlv exec mypackage --remote=10.0.0.1:1234 --password="password"
Connected to 10.0.0.1:1234
Type 'help' for list of commands.
(dlv) q
$ dlv exec myotherpackage --remote=10.0.0.1:1234 --password="password"
Connected to 10.0.0.1:1234
Type 'help' for list of commands.
(dlv) q

This would enable a developer to start the delve server once on the remote machine, and then to initiate and restart debug sessions on various packages all from within their development environment without having to go back to the server and restart the debugger.

I'm brand new to Go and Delve so if I've misunderstood something or there are reasons why this would be a bad idea I would be happy to be educated. - Thanks

_Edit: Added password parameter as per @aarzilli's suggestion._

[aarzilli]

So you want a service for authentication-less remote execution of arbitrary executables?

[hrobertson]

Good point. I was thinking within the context of my locked down environment, but authentication would be a good idea.

$ dlv server --listen=10.0.0.1:1234 --password="password"
...
$ dlv exec mypackage --remote=10.0.0.1:1234 --password="password"

[aarzilli]

We'd have to properly encrypt the password to be worth it... IMHO a script like:

set -e
ssh user@server dlv --headless=true --listen=$hostname:$port exec $1 &
sshpid=$!
dlv connect $hostname:$port  
kill $sshpid

is better.

[charles-dyfis-net]

--password on the command line is less-than-ideal: Command lines are exposed to all users on a system, which is why it's conventional to have other options -- such as passing a file name or socket (--passwordfile <(printf '%s' "password"), for example, doesn't expose your password in the same way --password password does; since printf is a shell builtin, it doesn't exec a child process with its command line arguments and thereby expose them).

[aarzilli]

Closing, doesn't seem like a good idea and it could be implemented independently of delve anyway.

[jacquayj]

@aarzilli @hrobertson Authentication implementation details aside, this seems like a great idea and totally reasonable feature request. My go development always takes place on a remote system, since the libraries I'm building against don't exist for MacOS. I'm sure I'm not the only one.

Maybe this idea is better suited as an external project... delve-server possibly? But as it stands, delve is useless for me without it (or without hacking a bunch of scripts on top of my editor).

[rthiggins]

As an embedded developer I use remote debugging all of the time. I've just started using go and I really appreciate the ease with which I can cross compile it, but it is a serious drawback not to be able to do remote debugging.

[fsunaval]

How do I get dlv to work with Go plugins?
Here's my scenario.
I compile a Go plugin as follows.
go build --buildmode=plugin -o function.so function.go

The plugin function.so is then invoked from another go executable.

I want dlv to be able to break into the function.so plugin.
Is this possible ?