search

microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.45k stars 1.53k forks source link

"miDebuggerPath" completely ignored when "debugServerPath" is used #3103

Open Yatekii opened 5 years ago

Yatekii commented 5 years ago

Describe the bug

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 commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@WardenGnaw for visibility.

Luka234 commented 3 years ago

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):

With v1.1.0-insiders3:

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 commented 3 years ago

@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] commented 3 years ago

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

Yatekii commented 3 years ago

Great job.

sean-mcmanus commented 3 years ago

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