Support debugging via SSH

[GitMensch]

This is different from remote-debugging, which needs a gdbserver on the other side.
It effectively means to ssh into a machine (possibly with client hoping), start GDB there and communicate with this GDB via SSH.

Everything that GDB sees is the ssh machine (using all native paths, having access to all local binaries and debug symbols); to see everything on the "client" side the sources (or a copy of those) need to be accessible to the client. The GDB side can have those, but would only need it to run list and search commands (because it operates on debug symbols in all other places).
Especially with a copy of the code the paths between the ssh machine and the local machine may be different, so the extension may need to do "translation" using a SourceFileMap array (when there's a UI-set breakpoint on the client (which always happens with the "local" paths), the path has to be translated to the "client view"). Similar when GDB tells "I've stopped on this line in that source" the path has to be translated in the other direction to be able to show it in the UI.

[jonahgraham]

@thegecko path mapping support is something we recently discussed, is there something in place we can use already?

[jonahgraham]

@GitMensch in this use case "who" handles the ssh'ing and launching of gdb on the remote machine? Once it starts up I assume that communication is as per normal?

[GitMensch]

The ssh'ing is done by the debug adapter for launching gdb. It is instructed to do so by the debug extension.

There are some node modules for ssh, if I remember they work well in general (especially https://github.com/mscdex/ssh2) and bring also support for client hoping, but don't support Kerberos), so the debug adapter may use those.

The communication is indeed then normal (apart from either the debug adapter or the debug extension doing the path mapping in both directions).

[jonahgraham]

Path mapping aside, can this be done with a script as the gdb, like what was done by this user for sudo? I am not proposing that as the end of it, just trying to understand how much configuration is required to support this? Eclipse IDE uses the extensive org.eclipse.remote + Eclipse RSE plug-ins to provide target management support including debugging. For now doing that seems out of scope of cdt-gdb-adapter, so I am trying to understand the missing pieces.

With ssh connectivity, how is new-ui handled? Presumably we need to open multiple ssh connections?

[GitMensch]

Path mapping aside, can this be done with a script as the gdb [...]

most likely (but configurable options in launch.json would be much superior, of course); if you need client hoping then you may need multiple scripts (one on each client that connects to the next until the final one that would start gdb)

With ssh connectivity, how is new-ui handled? Presumably we need to open multiple ssh connections?

very likely

[thegecko]

Unless I'm missing something, remote SSH debug should already be possible in a generic way using the VSCode Remote extension: https://code.visualstudio.com/docs/remote/ssh

path mapping support is something we recently discussed, is there something in place we can use already?

If you have a point where you can edit the MS-DAP messages directly, one approach could be to find/replace paths on the fly. I believe all paths are keyed on "path": "...":

    const PATH_PREFIX = '"path":"';

    protected replacePaths(message: DebugProtocol.ProtocolMessage, direction: 'incoming' | 'outgoing'): DebugProtocol.ProtocolMessage {
        if (!this.pathMapping) {
            return message;
        }

        let json = JSON.stringify(message);

        for (const [remote, local] of Object.entries(this.pathMapping)) {
            if (direction === 'incoming') {
                json = json.replace(new RegExp(PATH_PREFIX + remote, 'g'), PATH_PREFIX + local);
            } else {
                json = json.replace(new RegExp(PATH_PREFIX + local, 'g'), PATH_PREFIX + remote);
            }
        }

        return JSON.parse(json);
    }

Where this.pathMapping is extracted from the launch configuration and specified in the form "": "", e.g.

    ...
    "pathMapping": {
        "/src": "${workspaceFolder}"
    }
    ...

[GitMensch]

Unless I'm missing something, remote SSH debug should already be possible in a generic way using the VSCode Remote extension: https://code.visualstudio.com/docs/remote/ssh

This extension is only licensed to be run on "Visual Studio Code", you are not allowed to run it in self-built vscode installations and much less in Theia.

+1 concerning the path substitution suggestion.

[thegecko]

This extension is only licensed to be run on "Visual Studio Code", you are not allowed to run it in self-built vscode installations and much less in Theia.

👎

[GitMensch]

Yep, totally 👎for Microsoft's License here (of course the code is not available either)!
But: open-remote-ssh does work quite well in general (also for wsl scenario when manually enabling ssh there and map the changing ip of the wsl instance via host file; and if you handle the docker part yourself and have sshd enabled there then also works for that).

In general using "remote workspaces" do work for many scenarios, but not all, and it comes with quite some cost - debugging a ssh-connected "remote workspace" is quite different from "ssh debugging"!

The first needs (normally auto-installs) the reh-components of the server (matching to the client version) into the user home (yay, each user gets some 100MBs of binaries plus some 100MBs for the extensions) and launches quite some node processes that do the file handling and executing the extensions (for example the debug extension).
That does need a remote side that has working reh-components available (see MS's support list, it does not include all cpu architectures and kernels) as well as a remote side that can handle the load and - for the initial setup (which each changing client version) - either the option to auto-download the reh-components or otherwise a manual download (again, possibly for each user!).

Debugging via SSH only needs a working GDB (of course) and a working SSH, because everything but the executed GDB and binary are on the client (you don't even need gdbserver on the remote). Especially if you want to inspect core-dumps that option is much easier (needs no setup at all, only the matching sources on the client, which are also only needed for the context in the editor, if you are fine with "list" in the GDB console alone then there's no need for that [register, memory, variable, ... still work fine without sources]).