Escaped double quotes in postLaunchCommands = 'Problem parsing arguments' error

The upcoming OpenOCD 0.11.0 supports a new set of rtt commands. One of the commands requires that its last argument is wrapped in double quotes, e.g. rtt setup 0x20000000 49152 "SEGGER RTT".

Specifying that command with escaped double quotes in the postLaunchCommands results in a parsing error.

This is the launch.json file I used:

{
    "version": "0.2.0",
    "configurations": [
        {
            "cwd": "${workspaceRoot}",
            "executable": "./target/thumbv7em-none-eabihf/debug/stm-app",
            "name": "Debug Microcontroller (launch)",
            "request": "launch",
            "preLaunchTask": "rust: cargo build",
            "type": "cortex-debug",
            "runToMain": true,
            "configFiles": [
                "interface/stlink.cfg",
                "target/stm32l4x.cfg"
            ],
            "servertype": "openocd",
            "postLaunchCommands": [
                "monitor rtt setup 0x20000000 49152 \"SEGGER RTT\"", // <-
                "monitor rtt start",
                "monitor rtt server start 8765 0",
            ],
            "svdFile": "STM32L4x3.svd"
        }
    ]
}

I get the following pop-up error message when I try to use the above launch configuration:

Failed to launch GDB: Problem parsing arguments: interpreter-exec console "monitor rtt setup 0x20000000 49152 "SEGGER RTT"" (from interpreter-exec console "monitor rtt setup 0x20000000 49152 "SEGGER RTT"")

Is there a way to execute OpenOCD commands that contain double quotes after the main breakpoint has been hit (i.e. with "runToMain": true in the launch.json)?

Workaround

As a workaround I’m currently using an external GDB script file.

            "postLaunchCommands": [
                "source rtt.gdb",
            ],

$ cat rtt.gdb
monitor rtt setup 0x20000000 49152 "SEGGER RTT"
monitor rtt start
monitor rtt server start 8765 0

[Marus]

Yeah - once I put in a proper encoding fix (not sure if I expect this will come in 0.3.9 - as I’ve already started the 0.3.8 preparations then you’ll have to remove that extra \\ - but just thought that might be a nicer work-around than the source variation until I can do that.

[japaric]

thanks for the quick fix, 0.3.9 works nicely!