How to configure scheduler-locking gdb option in VSCode

I can add additional argument from launch.json to gdb by miDebuggerArgs

Something like this:

"MIMode": "gdb",
"miDebuggerArgs": "-ex 'help set scheduler-locking'",

works as expected

But why this one doesn't work?

"miDebuggerArgs": "-ex 'show scheduler-locking'",

Also doesn't work set scheduler-locking step

The option setupCommands gives me only errors: Unable to start debugging. Unexpected GDB output from command "-interpreter-exec console "set scheduler-locking step"". Target 'None' cannot support this command. It doesn't look useful

Is there any other option to setting up set scheduler-locking step before debug is paused on breakpoint?

Solution

TL;DR

Create a file somewhere, I suggest gdb.conf in your workspace root. Refer to that file in your launch config in .vscode/launch.json:

"miDebuggerArgs": "-x '${workspaceFolder}/gdb.conf'"

In the file, define hooks for post run and post attach (hooks described here):

echo Adding hooks for stop to "set scheduler-locking step"\n
define hookpost-run
  set scheduler-locking step
end
define hookpost-attach
  set scheduler-locking step
end

(If using GDB directly instead of via VS Code, you can use gdb -x gdb.conf)

Explanation

The Target 'None' cannot support this command. error happens when you attempt to set scheduler-locking step with no target. If you run bare gdb in a terminal and then the command (or include it with -ex), you'll get the same error. (Aside: it is possible to provide it with -ex or run early on, in this situation, if starting a process or attaching to one with -p).

VS Code's MI debugger starts GDB, runs all the setupCommands and then attaches, meaning that it will always run those commands early. Likewise if you try to supply with -ex.

Using the technique from this feature request, you can create a hook and have it run the set command then. The linked comment is slightly wrong so I won't directly quote.

(See TL;DR)

This tells GDB to create a hook to run after run and attach. You may also need target hookpost-remote instead if you use remote GDB (not tested).

Thus, when the hooks run, GDB is ready for the set command and it succeeds.

Note: do not include the command outside of the hook, because if it fails it will cause GDB to stop executing the commands in the file.

Background

Hopefully this will make it easier to find this answer from searching for strange step over/next behaviour in VS Code/GDB

GDB halts all threads on break, but releases them all when you continue or step the program. The command set scheduler-locking step tells GDB to lock all threads except the active thread when performing a step command (e.g. step/next). This means its much more intuitive when asking to step to the next line in GDB or an editor, as other threads won't interrupt.