Vscode-cpptools: ${workspaceFolder} does not convert correct path to gdb in WSL

[weinand]

_From @ajssousa on March 9, 2018 16:10_

• VSCode Version: 1.21.0
• OS Version: Windows 10 1709

Hi.

I have the WSL using Ubuntu and want to use gdb installed on WSL through the VSC.
Evertything works fine if i use the full path like in WSL (e.g. /mnt/c/Users/..)

The problem is if i want to use relative paths, the VSC is not converting an passing right to gdb inside WSL.

Steps to Reproduce:

1. 
   My setup:

        "name": "gdb using WSL bash",
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceFolder}/s3/S3IDMain",
        "args": [""],
        "stopAtEntry": false,
        "cwd": "${workspaceFolder}/s3/",
        "environment": [],
        "externalConsole": true,
        "pipeTransport": {
            "debuggerPath": "/usr/bin/gdb",
            "pipeProgram": "C:\\Windows\\sysnative\\bash.exe",
            "pipeArgs": ["-c"],
            "pipeCwd": ""
        },
        "sourceFileMap": {
            "/mnt/e": "e:\\"
        },
        "setupCommands": [
            {
                "description": "Enable pretty-printing for gdb",
                "text": "-enable-pretty-printing",
                "ignoreFailures": true
            }
        ]
    },

It says Unexpected GDB output from command "-environment-cd"

Using the ${workspaceFolder} or even using the Linux relative paths (../) he is not converting correctly to send to gdb. If the put the full path as a Linux style, no problem (e.g. of full path that works: /mnt/e/edws/svn-edws/s3/S3Trunk/S3/S3Mains ).

_Copied from original issue: Microsoft/vscode#45418_

[weinand]

_From @vscodebot[bot] on March 9, 2018 16:10_

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Global launch object in settings broken (#44050)
• GDB error (#43472)
  

[ajssousa]

Following the answer from Weinand in the old issue topic (vscode #45418):

weinand commented:

Today VS Code knows nothing about WSL. All WSL support must come from a debug extension.

My answer:

Ok, the WSL is the final use of the debug but the problem is not WSL.

The ${workspaceFolder} variable is always converting to Win32 type path. This is correct since I'm in Windows.
But it is possible to have a path translation for the ${workspaceFolder} to a Linux or Windows path type, maybe using a "Linux" or "Win32" tags like cpptools extension is using for the include paths in cpp projects?

[bobbrow]

If we can get a hook to resolve variables for tasks.json and launch.json, then we could define additional variables that would allow you to do this. The syntax might be slightly different, but it would at least give our extension some control over variable resolution. We have no way to do this right now.

Would you mind adding your scenario to this issue and upvoting it? https://github.com/Microsoft/vscode/issues/43782

[ajssousa]

Sure, I already added my scenario to the issue.

[MarcoScabbiolo]

Any workaround for this issue?

[lfurzewaddock]

I recently created a VS Code extension: WSL workspaceFolder, which may help.

[alan23273850]

Hello everyone, I have just used the following workaround to solve this issue.

Three options "program," "cwd," "debuggerPath" should be focused.

The most interesting one is "debuggerPath." In my setting, I first cd to the file's directory, and then compile the program with -g option again, and finally call gdb to execute debug procedure. The command "stdbuf -i0 -o0 -e0" before gdb is used to disable all buffers in order to enforce instant console output.

We can use the following option to see why we can perform "cd" and other commands in "debuggerPath."

Have fun!

[alan23273850]

Originally I want to use @lfurzewaddock 's extension because it seems very conveience. However it only supports workspaceFolder. I wonder what if the extension can support more paths such as $fileDirname or $file, etc. That makes the extension more popular.

[BenjaminDbb]

@alan23273850
thank you.
I tried and it works now. BTW, it is better to add:
"sourceFileMap": { "/mnt/c/" : "C:\\" }
in the launch.json, otherwise "FILE not found"

[alan23273850]

@BenjaminDbb

Thanks! I've originally added that line but it seemed useless on my computer so I commented it out.
Maybe for some devices it is still required. Thank you for your advice.

[KentoNishi]

I solved the issue by using @alan23273850's setup. Here is the full snippet, ready to copy-paste into launch.json's configurations!

{
    "name": "(gdb) Bash on Windows Launch",
    "type": "cppdbg",
    "request": "launch",
    "program": "${fileBasenameNoExtension}",
    "args": [],
    "stopAtEntry": false,
    "cwd": ".",
    "environment": [],
    "externalConsole": true,
    "pipeTransport": {
        "debuggerPath": "cd $(wslpath '${fileDirname}') && g++ ${fileBasename} -o ${fileBasenameNoExtension} -g -Wall && stdbuf -i0 -o0 -e0 gdb",
        "pipeProgram": "${env:windir}\\system32\\bash.exe",
        "pipeArgs": ["-c"],
        "pipeCwd": ""
    },
    "setupCommands": [
        {
            "description": "Enable pretty-printing for gdb",
            "text": "-enable-pretty-printing",
            "ignoreFailures": true
        }
    ]
}

[bobbrow]

We recommend using VS Code's integrated support for WSL. We won't be making any major changes to our "non-remote" implementation going forward.