VSCode中配置gdb scheduler-locking选项的问题及方案咨询

方法1：修正miDebuggerArgs的引号格式 #

你之前的配置失效大概率是JSON的引号解析问题，把单引号替换为转义后的双引号，或者在命令无歧义时直接省略引号：

"MIMode": "gdb",
"miDebuggerArgs": "-ex \"set scheduler-locking step\""

如果需要执行多个调试命令，用多个-ex参数串联：

"miDebuggerArgs": "-ex \"set scheduler-locking step\" -ex \"show scheduler-locking\""

方法2：使用gdb初始化文件（.gdbinit） #

1. 在项目根目录或用户主目录创建.gdbinit文件，写入调试配置命令：

set scheduler-locking step

2. 在launch.json中配置gdb加载该初始化文件，同时解决gdb的安全加载限制：

"MIMode": "gdb",
"miDebuggerArgs": "-iex \"set auto-load safe-path ${workspaceFolder}\" -x ${workspaceFolder}/.gdbinit"

-iex参数用来提前设置gdb允许加载当前目录的初始化文件，避免被安全策略拦截。

方法3：调整setupCommands的执行时机 #

之前setupCommands报错是因为命令执行过早（调试目标尚未启动），可以指定命令在程序停止时执行，这样首次断点触发时会自动完成配置：

"setupCommands": [
    {
        "text": "set scheduler-locking step",
        "ignoreFailures": false,
        "when": "stopped"
    }
]

虽然该命令在首次暂停后执行，但后续的单步调试会立即生效，基本满足需求。

方法4：提前启动程序并完成配置 #

通过miDebuggerArgs让gdb先启动程序到main函数入口，设置好调度锁定后再运行到断点：

"miDebuggerArgs": "-ex \"start\" -ex \"set scheduler-locking step\" -ex \"continue\""

start命令会让程序启动并停在main函数的第一条指令，此时设置调度锁定，再用continue运行到你的断点，确保断点触发前配置已经生效。

内容的提问来源于stack exchange，提问作者mr NAE