Using ${workspaceFolder} and sourceMapFile for remote debugging a Linux Cluster

[tabedzki]

Hi @pieandcakes,

First off, I just want to say thank you for all the hard work you and other members on your team are doing. The support here I've seen here on GitHub and the documentation on VS Code site is pretty extensive, especially for a project that doesn't seem to be monteized.

I am trying to remotely debug a program on our cluster (RedHat) from a Windows version of VS Code (1.24.0) and I would like some clarification about how some of the settings in the launch.json work and how they interact with each other. I am trying to run a simple program from https://github.com/dmrauch/vscode-cpp-remote-debug to test the capabilities; I can set breakpoints and remotely debug the program with the following configuration file:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "launch",
            "name": "Launch Program (SSH)",
            "target": "./build/debug/file1",
            "cwd": "${workspaceFolder}/",
            "ssh": {
                "host": "seas.upenn.edu",
                "cwd": "/mnt/rrio1/home/tabedzki/vscode-cpp-remote-debug",
                "keyfile": "C:/Users/tabedzki/AppData/Local/lxss/root/.ssh/id_rsa",
                "user": "tabedzki",
            }
        }
    ]
} 

I was previously able to use sourceFileMap to map my remote directory to my local mounted copy of the cluster when I was connecting a local copy of gdb to a remote copy of gdbserver:

{
    "version": "0.2.0",
    "configurations": [
      {
        "name": "(gdb) Launch Remote Debugging of file1",
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceRoot}/build/debug/file1",
        "miDebuggerServerAddress": "localhost:9091",
        "args": [],
        "stopAtEntry": false,
        "cwd": "${workspaceRoot}",
        "sourceFileMap": {
          "/home/tabedzki": "~/cluster/"
        }
      }
    ]
  }

Is there a way to do something similar with the first configuration file? I tried doing sourceFileMap but it does not appear to work either inside the ssh block or outside of it.

[pieandcakes]

@tabedzki

Your first configuration is not part of this extension. The line "type": "gdb" tells me this. Our extension launch.json "type" is "cppdbg". You will need to determine which extension is providing support for that type and talk to them.

If you want to use our extension through ssh, you can look at Pipe Transport to do something similar with our extension.

[tabedzki]

Ahh sorry about that. Is there a way to remotely debug over ssh using cppdbg? I have been having some trouble finding a native method of doing it.

[pieandcakes]

@tabedzki I posted a link in my previous comment. You can use our Pipe Transport documentation to do that. it does require you to have a local ssh client.

Take a look at the documentation and let me know if you need more help with that.

[tabedzki]

I'll take a more in depth look into the Pipe Transport tomorrow, right now I have a general setup that doesn't work but that might be me not getting the paths exactly right as opposed to not knowing how to set up the configuration. Is there anything glaringly wrong with this setup:

So from what I saw from the documentation, I have a general setup like this:

        {
            "name": "(gdb) Pipe Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/debug/file1",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "pipeTransport": {
                "debuggerPath": "/usr/bin/gdb",
                "pipeProgram": "/usr/bin/ssh",
                "pipeArgs": [
                    "-i",
                    "${env:HOME}/.ssh/id_rsa",
                    "[email protected]"
                ],
                "pipeCwd": "${workspaceFolder}",
                "sourceFileMap": {
                    "/home/chris": "/home/tabedzki"
                  }
            },
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": false
                }
            ]
        },

Also, does this support the "windows", "osx" and "linux" specific configurations that the VS Code in general supports supports?
Does the pipeCwd have to be explicit as in /home/tabedzki/vscode-app-remote-debug or can it use ${workspaceFolder} along with sourceFileMap?

[pieandcakes]

@tabedzki

Also, does this support the "windows", "osx" and "linux" specific configurations that the VS Code in general supports supports?

Yes, those should be supported.

Does the pipeCwd have to be explicit as in /home/tabedzki/vscode-app-remote-debug or can it use ${workspaceFolder} along with sourceFileMap?
pipeCwd is the current working directory for the pipe program. If you have the path to the pipe program fully specified, you can leave this empty.

Your program field needs to be the location of the program on the remote computer, not where it is locally on your current computer. This way of debugging uses a pipe program such as ssh to talk to gdb on the remote machine, therefore the program path must be the remote path.

Your sourceFileMap needs to be outside of the pipeTransport object.

[tabedzki]

Ok. I think this covers most things that I need. Thank you for your help!
One last thing: Do you how to reference the home directory for a windows user, aka C:\Users\tabedzki in VS Code? Would it be ${env:USERPROFILE} or something more akin to %{env:USERPROFILE}%?

[pieandcakes]

If you are doing it locally, it should be ${env:USERPROFILE} and then VS Code will resolve that environment variable before the call comes to us. If you want the OS to do the resolution, it is %USERPROFILE%.

[pieandcakes]

@tabedzki I'm going to go ahead and close the issue. If you need more information, please reopen.

[tabedzki]

Alright. Thank you for all your help!

[tabedzki]

It appears I have another point on which I need clarification:
In my launch.json I have a linux and windows specific commands and they both ssh into the cluster properly.

Using the below configuration, I thought VS Code would read the local ${WorkspaceFolder}and map it to the proper place on the cluster via the sourceFileMap, i.e., remap R:\ to /home/tabedzki for Windows and /home/chris/cluster to /home/tabedzki for Linux (those are both the respective mounted folders to /home/tabedzki). However, I get an error saying

Unable to start debugging. Unexpected GDB output from command "-environment-cd /home/chris/cluster/vscode-cpp-remote-debug". /home/chris/cluster/vscode-cpp-remote-debug: No such file or directory.

From what I gather, this means that VS Code is trying to read /home/chris/cluster/vscode-cpp-remote-debug on the cluster, which doesn't exist since the path is /home/tabedzki/vscode-cpp-remote-debug. (Please correct me if I am wrong.)

Can VS Code and the cpp extension read the workspaceFolder variable and swap out the paths to the folder or does the pipCwd have to be explicit to the folder as in /home/tabedzki/vscode-cpp-remote-debug?

Thanks in advance

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Pipe Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/debug/file1",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "linux": {
                "sourceFileMap": {
                    "/home/chris": "/home/tabedzki"
                  },
                "pipeTransport": {
                    "debuggerPath": "/usr/bin/gdb",
                    "pipeProgram": "/usr/bin/ssh",
                    "pipeArgs": [
                        "-i",
                        "${env:HOME}/.ssh/id_rsa",
                        "[email protected]"
                    ],
                    "pipeCwd": "${workspaceFolder}",
    
                },
            },
            "windows": {
                "sourceFileMap": {
                    "/home/tabedzki/": "R:\\"
                  },
                "pipeTransport": {
                    "debuggerPath": "/usr/bin/gdb",
                    "pipeProgram": "C:/Program Files/Git/usr/bin/ssh.exe",
                    "pipeArgs": [
                        "-i",
                        "${env:USERPROFILE}/.ssh/id_rsa",
                        "[email protected]"
                    ],
                    "pipeCwd": "${workspaceFolder}",
                    
                }
            },
            
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": false
                }
            ]
        }
    ]
}

[pieandcakes]

@tabedzki the sourceFileMap is there to map compile time source location to where source is on your local machine, to aid in loading source so you can debug, because the debugger's symbol information that it accesses is usually determined at compile time. It does not modify paths sent to the debugger at all.

For your example, you need to change "cwd" to be the working directory on the cluster. When specifying program and cwd, it needs to be done relative to gdb which sits on the cluster, since that is what we pass to gdb.

pipeCwd is only the working directory for the pipe command. This tells the pipe program which folder it is running out of and has nothing to do with a working directory relative to debugging.