Support connecting to a debug adapter instance running remotely without having to write extension glue code

[daandemeyer]

Currently, a debug adapter extension can specify a program in it's package.json and users can use the debug adapter extension without any extension code required. However, in this setup, vscode will always start its own instance of the program specified in "program" in the debug adapter's package.json. For remote debugging, an instance of the debug adapter will have already been started and will be running remotely on a specific host/port. VSCode currently doesn't seem to support connecting to a remote instance of a debug adapter without wiriting extension glue code. Ideally, we could set "host" and "port" options in launch.json which would automatically instruct vscode to instantiate an instance of DebugAdapterServer with the given host and port instead of DebugAdapterExecutable so that it connects to a remote instance of the debug adapter instead of trying to start it locally.

[weinand]

It does not make sense to hardcode a server address and port number in the package.json (which is part of an extension and unmodifiable).
Using the DebugAdapterServer or the DebugAdapterNamedPipeServer extension APIs is the way to go.

For remote scenarios I suggest to use the "RemoveDevelopment" extension which runs debug extensions (and their adapters) automatically in a remote location and takes care of all communication issues.

[daandemeyer]

I specifically mentioned adding these options to launch.json and not to package.json. In fact, that's what vscode already supports via the debugServer attribute but that only allows specifying the port and not the host. See the linked PR which adds the debugServerHost attribute so the host can be specified as well.

[weinand]

Since we want to keep the number of VS Code-defined launch.json attributes small, we are reluctant to add any new attributes. The "debugServer" attribute only exists for historical reasons.

A "host" attribute would be of very limited use, since running a debug adapter remotely breaks the VS Code assumption/restriction that both the debug adapter and VS Code has access to the same filesystem. So the "host" attribute could not be used with debug extensions that are not really prepared for this.

(VS Code's official way around this restriction is the "RemoveDevelopment" extension mentioned above).

[daandemeyer]

Unfortunately, the remote development extensions can't be preinstalled which makes them extremely frustrating to use when the remote host is a test container/vm that is rebuilt from a base image as part of a build.

You're right about the filesystem assumption, that's exactly what I encountered just now when trying to test this. As a workaround I'm going to fall back to the C++'s extension's pipeTransport for now.

[weinand]

Daan De Meyer (@daandemeyer) then let's try to investigate the first problem ("remote development extensions can't be preinstalled"). I'm not sure that this is really a problem...

---

BTW, some extensions explicitly support remote debugging (if the underlying runtime supports this). E.g. JavaScript debugging can connect to a remote runtime and in this case the extension provides a configurable mapping between remote and local file system paths. In this case the debug adapter still runs locally but talks to a remote runtime (or gdb). This approach was the precursor of the "remote development" extension. I think the C++ and C# debug extensions support something similar.

[daandemeyer]

Daan De Meyer (@daandemeyer) then let's try to investigate the first problem ("remote development extensions can't be preinstalled"). I'm not sure that this is really a problem...

See microsoft/vscode-remote-release#1718. When building container/vm test images, these images are rebuilt from a base image every time a build is done. Since vscode-server can't be preinstalled, every time we build a new test image, we have to reinstall vscode-server and the remote extensions which is rather slow.

If you're curious about the setup: http://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html. This is pretty niche but the same problems apply when using docker instead of mkosi.

BTW, some extensions explicitly support remote debugging (if the underlying runtime supports this). E.g. JavaScript debugging can connect to a remote runtime and in this case the extension provides a configurable mapping between rmeote and local file system paths. This approach was the precursor of the "remote development" extension. I think the C++ and C# debug extensions support something similar.

Yes, this seems to be the pipeTransport launch.json config option of the C++ extension. The only annoying thing about this is that it requires the source code to be available on the remote host which isn't the case in my scenario. (But I will be making changes to make the source code available on the remote host so I can use pipeTransport).

In the absolute ideal scenario, the debug adapter protocol would allow debugging on a remote host without having the source code available on the remote host. Requests from the debugger to access specific source files would be routed from the remote host to the local host running vscode which would provide the requested source file to the debugger. As I understand it, we're not there yet though since this approach would require changes to debuggers such as lldb as well which currently expect the source code to be available somewhere on the remote host filesystem.

For now, I can make things work by copying over the source code to the container/vm and using the pipeTransport option. Thanks for the quick answers!