Vscode-cpptools: [Feature Request] Separate SetupCommands for before and after debuggee info passed to gdb

[Stragarp]

I'm trying to pass some extra commands after the launch of GDB. These commands are working if I enter them manually in the debug console of Visual Studio, prefixed with "-exec", after GDB started. I'd like to use setupCommands to do it automatically with the launch.json file. Here is what my file looks like :

{
            //General
            "name": "PyraDebug",
            "type": "cppdbg",
            "request": "launch",
            "program": "/Users/Squarp/Code/pyrapro/build/pyrapro/pyrapro.elf",
            "targetArchitecture": "ARM",
            "launchCompleteCommand": "None",            
            "cwd": "${workspaceFolder}",            
            "externalConsole": false,       

            //GDB Server
            "MIMode": "gdb",
            "miDebuggerServerAddress": "localhost:3333",
            "miDebuggerPath": "/Users/Squarp/Code/opt/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gdb",
            "miDebuggerArgs": "",
            "stopAtEntry": true,
            "serverLaunchTimeout": 2000,
            "setupCommands": [
                {"text": "monitor reset halt"},
                {"text": "load"},
                {"text":"continue"}
            ],
            "customLaunchSetupCommands": [],
            "logging": { "engineLogging": true, "trace": true, "traceResponse": true } 

            //Tasks
            // "preLaunchTask": "rebuild"


        }

And the error :

Unable to start debugging. Unexpected GDB output from command "-interpreter-exec console "monitor reset halt"". "monitor" command not supported by this target.

Those commands are pretty classic, I tried many things but I'm stuck now. Everything is working fine if I enter those in Terminal.

Any help would be greatly appreciated.

[pieandcakes]

@Stragarp Can you tell me if the debuggee needs to be running before you send monitor reset halt?
I see you have the enginelogging enabled. can you share the output from that? I'm wondering if it is the timing of when it is sent that it isn't happy with.

[Stragarp]

Hi @pieandcakes thanks for the answer.
I think it is exactly what you described, the command is unknown because gdb is not connected to the server yet when it tries to pass it.

After several hours of wandering on the internet, I found a solution that works fine. I'll post it there in case someone faces the same problem.

The actions I want to accomplish in the right order are :
-Start the server (Jlink gdb server in this case)
-Start local gdb and connect to server
-Pass some args (reset, load and continue)

Here is my 'launch.json':

{          
            //General
            "name": "Debug",
            "type": "cppdbg",
            "request": "launch",

            //GDB Client
            "MIMode": "gdb",
            "miDebuggerServerAddress": "localhost:3333",
            "miDebuggerPath": "/Users/Code/opt/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gdb",
            "miDebuggerArgs": "-x ${workspaceFolder}/.gdbinit",

            //GDB Server
            "debugServerPath": "/Applications/SEGGER/JLink_V634f/JLinkGDBServer",
            "debugServerArgs": "-if SWD -device STM32F769BG -port 3333",
            "serverStarted":"Connected to target",

            "program": "/Users/Code/strgg/build/strgg/strgg.elf",            
            "cwd": "${workspaceFolder}",            
            "externalConsole": false,
            "stopAtEntry": false,

            //Lancement du build avant de démarrer le serveur
            // "preLaunchTask": "rebuild"
            //Debug
            // "logging": { "engineLogging": true, "trace": false, "traceResponse": false },

        }

And the .gdb init specified in "miDebuggerArgs": "-x ${workspaceFolder}/.gdbinit:

define target hookpost-remote
monitor reset
load
end

Which uses a hook to wait for the execution of the command target remote to execute the commands.

There might be a way to use setupCommands and not the .gdbinit file but I tried many things without success, so I think I'm going to go with this.

[pieandcakes]

@Stragarp thank you for providing a solution. It sounds like it is timing dependent and may warrant a further look when we have time to see if we can offer a pre and post set of commands to run before and after the debuggee is loaded.

[ianjfrosst]

This is still an issue. #2517 is a duplicate.