Vscode-cpptools: Bug in case of debugging BareMetal over GDB

[anpilog]

Hi,

• does anyone have an idea how it could be fixed without waiting for next version of cpptools?
• hope it's going to be fixed in release

_Details_

I've tried to debug baremetal arm MCU from VSCode and it seems working in general.
However there few pretty nasty nuances in configuration...

To get things running I had to manually specify custom lunch commands:

• connect to remote target (running on background OpenOCD)
• stop potentially running MCU
• load firmware into MCU

At first I used only "load" command but figured out that gdb doesn't have file with symbols preloaded.
It was a surprise because I expected from configuration file that gdb would be run like this:

$(miDebuggerPath) $(program)

But it appears to be not...
So I had to manually load ELF file into gdb with "file" or "load" command.
Profit? No... 8(

There is a problem.
I would define path to ELF file by using ${workspaceRoot}.
But path includes white-space and it can't be processed correctly.
GDB nativelly supports it by wrapping path to file in "".
But when I try to define path as

"text": "file \"${workspaceRoot}\\.build\\mcu-test.elf\"",

or

"text": "file '${workspaceRoot}\\.build\\mcu-test.elf'",

vscode:cpptools corrupt it and GDB can't recognize it either.

Because cpptools uses MIEngine that doesn't have this issue I would guess that the bug is in cpptools.
It looks like when customLaunchSetupCommands is defined then program is not passed to debugger.

Here is my launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "C++ Launch (GDB)",
            "type": "cppdbg",
            "request": "launch",
            "launchOptionType": "Local",
            "targetArchitecture": "arm",
            "miDebuggerPath": "path-to-arm-toolchain/arm-none-eabi-gdb.exe",
            "filterStderr" : true,
            "customLaunchSetupCommands": [
                {
                    "text": "target remote :3333",
                    "description": "connect to remote target",
                    "ignoreFailures": false
                },
                {
                    "text": "monitor reset halt",
                    "description": "halt",
                    "ignoreFailures": false
                },
                {
                    "text": "file c:/mcu-test.elf",
                    "description": "load symbols",
                    "ignoreFailures": false
                },
                {
                    "text": "load",
                    "description": "load to remote MCU",
                    "ignoreFailures": false
                }
            ],
            "program": "${workspaceRoot}\\.build\\mcu-test.elf",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${workspaceRoot}",
            "externalConsole": true
        }
    ]
}

[delmyers]

@anpilog I'm trying to understand your request right here. Remote debugging to an arm device isn't a scenario that we have tested. It seems that you are having issues because of spaces in your folder name, and that isn't working correctly for you. Also, it looks like you are debugging on Windows, correct? If we were to fix the problem with the path, would that be enough to unblock you?

[anpilog]

All is correct.

We can look on this issue like this:
Remote debug is a use case where I faced the issue.
And the issue is that path with white-space processed in a wrong way.
If I could use ${workspaceRoot} in customLaunchSetupCommands then it's definitely removes showstopper.

However there is other thing:
I would expect that if 'program' is defined then it's passed to gdb as argument and thus symbols and sections are read. But it doesn't happen in case if 'customLaunchSetupCommands' defined.

[delmyers]

@anpilog I tested this out today on my windows box using mingw/gdb where my ${workspaceRoot} has spaces in it, and I'm not seeing an issue. Could this be an issue with your version of gdb? What version are you using? Also, is it this portion:

{
 "text": "file c:/mcu-test.elf",
  "description": "load symbols",
  "ignoreFailures": false
}

[delmyers]

@anpilog I was able to get this to work with mingw and gdb (I don't have one of the arm devices that you are working with), I just had to work around the fact that json and gdb will both try to escape the characters. For example:

"text": "file ${workspaceRoot}/myfile.elf"

Worked with any of the following:

"text": "file \"${workspaceRoot}\\\\myfile.elf\"" (double escaped back slashes, and escaped quotes)
"text": "file '${workspaceRoot}/myfile.elf'" (single quotes and forward slash)
"text": "file \"${workspaceRoot}/myfile.elf\"" (escaped quotes and forward slash)
"text": "file '${workspaceRoot}\\\\myfile.elf'" (double escaped back slashes, and single quotes)

You might have varying success based on your version of gdb.

[anpilog]

Hi @delmyers

I'm using GDB from GNU ARM Embedded Toolchain project https://launchpad.net/gcc-arm-embedded

c:\mesheven\MeshEmbedded-0.0.5\tools\toolchain\bin>arm-none-eabi-gdb -v
GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.1.20141128-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".

And I've tried all combinations you mentioned. None worked for me.

I'll try latest version of GDB tomorrow and let you know.

BTW, do you know why customLaunchSetupCommands overrides program setting?

[jacdavis]

"BTW, do you know why customLaunchSetupCommands overrides program setting?" - customLaunchSetupCommands completely replaces the set of MI commands we use when launching. If you just want to add to the set of commands, you can use the setupCommands option to append to our default sequence.

[pieandcakes]

@anpilog you can also enable "logging": { "trace": true, "traceResponse": true} in the launch.json and see what commands we send to gdb and get back. This may help you see what is or isn't being set up.

Also we recently enabled pipeTransport and this can be configured to connect directly to the remote gdb instance without gdbserver.

[anpilog]

@pieandcakes Thanks for update.
I'll try. Shell we close this conversation and continue at #321 ?
Seems like same issue to me.

[DTibbs]

Just wanted to add a comment for anyone coming upon this as I did.
I found adding a customLaunchSetupCommand of cd ${workspace} for arm-none-eabi-gdb gets gdb at least relative to your project, so you don't have to hard-code full paths with a bunch of \\\\

For example:

      "program": "${workspaceRoot}/build/debug/firmware.elf",
      "windows": {
        "MIMode": "gdb",
        "miDebuggerPath": "arm-none-eabi-gdb.exe",
        "customLaunchSetupCommands": [
          {
            "text": "cd ${workspaceRoot}"
          },
          {
            "text": "target remote localhost:3333",
            "description": "connect to remote target",
            "ignoreFailures": false
          },
          {
            "text": "monitor reset halt",
            "description": "halt",
            "ignoreFailures": false
          },
          {
            "text": "file build/debug/firmware.elf",
            "description": "load symbols",
            "ignoreFailures": false
          },
          {
            "text": "load",
            "description": "load to remote MCU",
            "ignoreFailures": false
          }
        ]
      },

Hope that helps!
Thanks for all the previous discussion that led me to this solution.