Vscode-cpptools: "miDebuggerPath" completely ignored when "debugServerPath" is used

[Yatekii]

Describe the bug

• OS and Version: Windows/Linux (Version does not matter)
• VS Code Version: Does not matter.
• C/C++ Extension Version: UPSTREAM (0.21.0)
• Other extensions you installed (and if the issue persists after disabling them): Does not have any influence.
• A clear and concise description of what the bug is:

When you specify a debugServerPath and a debugServerArgs, miDebuggerPath and miDebuggerArgs are completely ignored. Furthermore you HAVE to specify a miDebuggerServerAddress even tho that is not necessarily required as you can specify this via miDebuggerArgs

To Reproduce
Please include a code sample and launch.json configuration.
See the launch.jsonbelow:

{
    "version": "0.2.0",
    "configurations": [
      {
        "name": "COM Example",
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceRoot}/target/thumbv7em-none-eabihf/debug/examples/com",
        "args": [],
        "miDebuggerServerAddress": "localhost:2331",
        "stopAtEntry": true,
        "cwd": "${workspaceRoot}",
        "environment": [],
        //"externalConsole": true,
        "linux": {
          "MIMode": "gdb"
        },
        "osx": {
          "MIMode": "gdb"
        },
        "windows": {
          "MIMode": "gdb",
          "setupCommands": [{
            "text": "load"
          }],
          //"preLaunchTask": "cargo build com",
          "debugServerPath": "C:\\Program Files (x86)\\SEGGER\\JLink_V640\\JLinkGDBServerCL.exe",
          "debugServerArgs": "-select USB -device nRF52840_xxAA -endian little -if SWD -speed 4000 -noir -LocalhostOnly",
          "miDebuggerPath": "C:\\Program Files (x86)\\GNU Tools ARM Embedded\\8 2018-q4-major\\bin\\arm-none-eabi-gdb.exe",
          "miDebuggerArgs": "-q -x debug.gdb target/thumbv7m-none-eabi/debug/examples/com",
        }
      }
    ]
  }

Steps to reproduce the behavior:

1. Use the launch.json above.

Additional context
I tried finding the source code that uses the miDebuggerPath etc, but I can't even locate the variable in this repo. So I can't even see how this extension ever uses that value. If I could, I would fix it myself, but the entire extension is really intransparent, including all the config explanations (especially the problemMatcher).

[pieandcakes]

@Yatekii The code is at https://github.com/microsoft/miengine as that is where everything is passed to and processed.

When a debugServer is specified, we will be using that debug server exclusively and no other debugger. Can you expand why you are using both?

CC: @Robotdad @paulmaybee

[Yatekii]

No, it will still use GDB and not just the server, but it will use the wrong GDB (At least I see the GDB CLI in VSCode ...). I need to pass various params into GDB and I need the ARM GDB.
Specificially I need to download a file onto my remote target (embedded MCU).
This behavior makes no sense if you still use some GDB on top of the server ;)

[hcsch]

I too am currently experiencing issues with this. I want to debug a compiled firmware using simavr and avr-gdb. I have tried to do this with the following launch.json (running on Linux):

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "gdb (launch simavr)",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/SPOS.elf",
            "cwd": "${workspaceRoot}",
            "externalConsole": false,
            "stopAtEntry": true,
            "MIMode": "gdb",
            "miDebuggerPath": "/usr/bin/avr-gdb",
            "miDebuggerServerAddress": "localhost:1234",
            "debugServerPath": "/usr/bin/simavr",
            "debugServerArgs": "-v -v -v -g -m atmega644 -f 20000000 ${workspaceRoot}/SPOS.elf",
            "serverStarted": "avr_gdb_init listening on port 1234",
            "serverLaunchTimeout": 2000,
            "preLaunchTask": "make clean then make all"
        },
        {
            "name": "gdb (attach to simavr)",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/SPOS.elf",
            "MIMode": "gdb",
            "miDebuggerPath": "/usr/bin/avr-gdb",
            "miDebuggerServerAddress": "localhost:1234",
            "externalConsole": true,
            "cwd": "${workspaceRoot}"
        }
    ]
}

The gdb (attach to simavr) works with a manually started instance of simavr (using exactly the same parameters). gdb (launch simavr) however does not. It fails with the message Unable to start debugging. Debug server process failed to initialize.. To me it is not obvious why this isn't working. (Note: The launch timeout is not at fault. I have tried this with much higher timeouts and simavr is, in my experience, up and running after barely a second has passed.)

Please do correct me if I am making some wrong assumptions here, but the UI and the online docs show no hints as to what is happening (e.g. the usual "you can't use property Y with property X present"), there are no helpful logs (that I could find with a reasonable amount of googling), no easy way to troubleshoot, just an unexpected error. I would consider this a design bug, if this is indeed by design.

[Yatekii]

The classical Microsoft way of handling such things is "wontfix" and "works for me". I wouldn't expect them to change this behavior after another year went by.

We wrote our own vscode plugin in the meantime that handles things correctly, at least for Rust.

[pieandcakes]

@WardenGnaw for visibility.

[Luka234]

I have similar (or same) situation with exception that it all worked with C/C++ Extension Version v1.0.1 and stop working in v1.1.0-insiders3.

With launch.json below, this is (valid) behavior that I observe with v1.0.1 (in windows):

• jlinkgdbserverstart.bat is executed (debugServerPath) and I can see jlink server instance running in windows
• arm-none-eabi-gdb.exe (miDebuggerPath) attach (connect) to jlink debug server
• setupCommands are sent to target device
• debug working in vscode
• gdb link with jlink server is disconnected on debug stop

With v1.1.0-insiders3:

• jlinkgdbserverstart.bat is not executed (debugServerPath)
  If I add "miDebuggerServerAddress": "localhost:2331" then debugServerPath is executed but then miDebuggerPath is not used.

It seams like behavior change is introduced in MIEngine with https://github.com/microsoft/MIEngine/pull/1056 (It's just a guess based on not to deep digging).

{
    "version": "0.2.0", 
    "configurations": [
        {
            "name": "[MCU/GDB] Debug/JLink", 
            "type": "cppdbg", 
            "request": "launch", 
            "program": "${workspaceRoot}/build/${workspaceFolderBasename}.elf", 
            "windows": {
                "miDebuggerPath": "C://toolchain//gnu//arm-none-eabi-gdb.exe", 
                "debugServerPath": "${workspaceRoot}/jlinkgdbserverstart.bat", 
                "externalConsole": true
            }, 
            "linux": {
                "miDebuggerPath": "/usr/local/gcc-arm-none-eabi/bin/arm-none-eabi-gdb", 
                "debugServerPath": "${workspaceRoot}/jlinkgdbserverstart.sh", 
                "externalConsole": false
            }, 
            "stopAtEntry": true, 
            "cwd": "${workspaceRoot}", 
            "environment": [], 
            "MIMode": "gdb", 
            "miDebuggerArgs": "--cd=${workspaceRoot}", 
            "setupCommands": [
                ... my specific gdb commands to load firmware to arm target etc...
            ],
            "preLaunchTask": "[Misc][Debug] Create JLink GDB server script"
        }
    ]
}

jlinkgdbserverstart.bat -> this is generated with preLaunchTask [Misc][Debug] Create JLink GDB server script. Example of content is:
JLinkGDBServerCL -singlerun -select USB=440150122 -device EFM32GG380F512 -endian little -if SWD -speed 4000 -i

[WardenGnaw]

@Luka234 Your issue seems to be specific to 1.1.0-insiders3. I have moved it to its own issue: https://github.com/microsoft/vscode-cpptools/issues/6411

[github-actions[bot]]

This issue has been closed automatically because it's labeled as 'by design'.

[Yatekii]

Great job.

[sean-mcmanus]

@WardenGnaw This isn't "by design", right?