Give an option to have VSCode act as the server that you'd connect to from delve when you specify the --client-addr when running dlv dap`.

[adriancuadrado]

Is your feature request related to a problem? Please describe.
I want to be able to debug a program in a remote machine, but I don't have access to the firewall and router to open a port that I would specify with --listen when running dlv dap.

Describe the solution you'd like
I'd like to be able to specify a port VSCode should listen to for connections so I can use dlv dap --client-addr

Describe alternatives you've considered
I could create a tunnel to the remote machine or send the source code and open VSCode and connect with SSH, but I think it would be more appropriate if we were able to actually use a feature that is already available in dlv dap for this kind of thing.

Additional context
N/A

[hyangah]

Please tell us why you need other than the existing remote debugging paths. There are two options.

https://github.com/golang/vscode-go/wiki/debugging#remote-debugging

ps. All the dlv dap features were designed/implemented to be used in the VS Code (and our team is the original contributor to dlv dap). So, it's a bit strange to hear that there is a feature available in dlv dap and we are not using it.

[adriancuadrado]

@hyangah

Please tell us why you need other than the existing remote debugging paths.

I'll just quote myself:

I want to be able to debug a program in a remote machine, but I don't have access to the firewall and router to open a port that I would specify with --listen when running dlv dap.

---

My understanding is that --client-addr is meant to be used to allow the user to have dlv dap act as a client, as opposed to --listen, which would make dlv dap act as a server. But I don't see any way to specify in the launch.json file that VSCode should be waiting for connections that would be initiated by dlv dap when run with its --client-addr option.

ps. All the dlv dap features were designed/implemented to be used in the VS Code (and our team is the original contributor to dlv dap). So, it's a bit strange to hear that there is a feature available in dlv dap and we are not using it.

What are you using --client-addr for, other than using an integrated or external terminal?

vscode-go/extension/src/goDebugFactory.ts

Lines 379 to 384 in bd65f44

	if (
	!dlvExternallyLaunched &&
	(configuration.console === 'integratedTerminal' || configuration.console === 'externalTerminal')
	) {
	return this.startDAPServerWithClientAddrFlag(configuration, logErr);
	}

vscode-go/extension/src/goDebugFactory.ts

Lines 439 to 452 in bd65f44

	dlvArgs.push(`--client-addr=:${port}`);
	super.sendMessageToClient({
	seq: 0,
	type: 'request',
	command: 'runInTerminal',
	arguments: {
	kind: console,
	title: `Go Debug Terminal (${launchAttachArgs.name})`,
	cwd: dir,
	args: dlvArgs,
	env: env
	}
	});

Shouldn't it be possible to achieve the same running --listen instead of --client-addr from dlv dap and have VSCode connect to it? The only one place in this VSCode plugin where this option seems to be used doesn't really look as if you actually needed it there because you could rely on --listen instead.

[hyangah]

You don't need dlv dap to work as a client. VS Code is a complete DAP client. The 'remote' setup is for the case where dlv is running somewhere and VS Code can directly connect to the server.

My understanding is that --client-addr is meant to be used to allow the user to have dlv dap act as a client, ...

No, I added --client-addr to support exclusively for runInTerminal support in local environment (not for remote mode).
#1626

In your case, I wonder if unix socket support (#3216) may help instead.

[adriancuadrado]

@hyangah

You don't need dlv dap to work as a client. VS Code is a complete DAP client. The 'remote' setup is for the case where dlv is running somewhere and VS Code can directly connect to the server.

But what if that somewhere happens to be a machine whose router and firewall configurations won't allow me to use a port to listen? I could still debug the program, but only if VSCode were the one acting as a server. But that ain't happening because I guess I can connect to the machine using VSCode's remote development plugins and send the source code to the machine and debug from there instead of asking you to implement this feature to be able to debug directly on my personal computer instead.

My understanding is that --client-addr is meant to be used to allow the user to have dlv dap act as a client, ...

No, I added --client-addr to support exclusively for runInTerminal support in local environment (not for remote mode).
#1626

In your case, I wonder if unix socket support (#3216) may help instead.

I need help to understand how could unix sockets possibly offer any help to connect to a remote machine when they are meant for interprocess communication on the same machine. Other than not having to listen to any port if I were to use VSCode remote development plugin to connect to the machine, but that would imply that you aren't really understanding my problem. I just wondered if it would be possible to implement a feature that felt like should be there because that seemed like what --client-addr was meant for, but it seems like I just got it wrong that --client-addr was meant to have dlv dap act as a client (even if it can be used for that) because it was instead meant only to implement integrated and external terminals (even though you shouldn't really need it to implement them, since you could also just have used --listen instead and tell VSCode to connect to it as a client).