Vscode-cpptools: miDebuggerPath value when gdb is in Windows PATH

Created on 24 Jan 2019  路  9Comments  路  Source: microsoft/vscode-cpptools

Type: Debugger

  • OS and Version: Windows version 10.0.17763.253
  • VS Code Version: 1.30,2
  • C/C++ Extension Version: 0.21.0
  • Other extensions you installed (and if the issue persists after disabling them): NA

To Reproduce

Building and debugging any C program using MINGW64, when miDebuggerPath in launch.json is unspecified or set to "gdb", results in the error below. System PATH variable has gdb.exe. Setting miDebuggerPath to "gdb.exe" does not cause the error.

error

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/examples/introduction/hello",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}
debugger fixed (release pending)

Most helpful comment

This is really quite critical for cross-platform embedded development. "miDebuggerPath": "arm-none-eabi-gdb" should succeed regardless of whether it's called arm-none-eabi-gdb or arm-none-eabi-gdb.exe. That's standard behaviour even on Windows CLI!

All 9 comments

@tewarid Pretty sure you need to specify the file extension .exe on gdb in your miDebuggerPath for that to work.

@pieandcakes Yes, it does work with the .exe extension. I am wondering why it doesn't work without the extension (useful for cross-platform situations) or if you don't specify miDebuggerPath (gdb is in PATH).

@tewarid Because on Windows the file extension isn't assumed and is part of the file name. We don't do a lookup because we don't know what gdb you are using. A lot of people use cross compiled gdbs where the name isn't just gdb.exe.

Could the logic not be adjusted so that if the given string is not valid, it appends ".exe" and tries again? It would be nice if you could use the same launch config for Linux and Windows assuming the name of the gdb executable is the same on both?

The same issue with this I have also. I would like to provide a repository setup without any absolute addresses found only on my environment (e.g. C:/ProgramData/chocolatey/lib/mingw/tools/install/mingw64/bin/gdb.exe), but to just scan for kits (similarily as CMake Tools extension does it)

This is really quite critical for cross-platform embedded development. "miDebuggerPath": "arm-none-eabi-gdb" should succeed regardless of whether it's called arm-none-eabi-gdb or arm-none-eabi-gdb.exe. That's standard behaviour even on Windows CLI!

I found a solution.
Make a copy of gdb.exe in the same folder, then rename it to gdb.
Now you can click the debug icon of CMake on VS Code status bar, gdb will be launched normally!

gdb

Instead copy gdb.exe to gdb, Symbol Link gdb to gdb.exe may works too on NTFS partition, I haven't test it.

Was this page helpful?
0 / 5 - 0 ratings