Unable to pause, step button while using gdb connect to remote gdbserver

Environment

• OS and version: Windows_NT x64 10.0.19043
• VS Code: Version: 1.90.0 (user setup)
• OS and version of remote machine (if applicable): ARM Linux
• GDB / LLDB version: aarch64-linux-gnu-gdb.exe --version
  GNU gdb (Linaro GDB 2017.08) 7.12.1.20170202-git
  This GDB was configured as "--host=x86_64-w64-mingw32 --target=aarch64-linux-gnu".
• GDB server version: ./gdbserver --version
  GNU gdbserver (Linaro GDB 2017.08) 7.12.1.20170202-git
  gdbserver is free software, covered by the GNU General Public License.
  This gdbserver was configured as "aarch64-linux-gnu"

Bug Summary and Steps to Reproduce

Bug Summary:
I try using VS Code debug to connect remote gdbserver, and the button of pause, step, and others can not work, so I can not pause while debuging without breakpoint.
The break point can work only if it is set and send to server before debug is running. It can not add new break point while running debug.
Can it work like local debug when I use gdbserver to debug remote program?

launch.json

Debugger Configurations

{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "g++",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/${fileBasenameNoExtension}",
"args": [
"test.xml"
],
"cwd": "${workspaceFolder}",
"stopAtEntry": false,
"externalConsole": false,
"useExtendedRemote": true,
"MIMode": "gdb",
"targetArchitecture": "arm",
"logging" : {
"trace": true,
"traceResponse": true,
"engineLogging": true
},
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "set up remote debug program",
"text": "set remote exec-file ${fileBasenameNoExtension}",
"ignoreFailures": false
}
],
"miDebuggerPath": "D:/aarch64-linux/bin/aarch64-linux-gnu-gdb.exe",
// "miDebuggerPath": "/usr/bin/gdb-multiarch",
"miDebuggerServerAddress": "192.168.1.136:2000"
}
]
}

Debugger Logs

when I push the pause button, the gdbserver log trace info like that:
1: (10454) <-1045-exec-interrupt
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (10461) ->1045^done\r\n"},"seq":905}
1: (10461) ->1045^done
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (10461) ->(gdb)\r\n"},"seq":907}
1: (10461) ->(gdb)
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (10461) 1045: elapsed time 7\r\n"},"seq":909}
1: (10461) 1045: elapsed time 7
--> R (pause-17): {"type":"response","request_seq":17,"success":true,"command":"pause","body":{},"seq":911}
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (10465) ->&"\n"\r\n"},"seq":913}
1: (10465) ->&"\n"
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (10466) ->^done\r\n"},"seq":915}
1: (10466) ->^done
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (10466) ->(gdb)\r\n"},"seq":917}
1: (10466) ->(gdb)
<-- C (pause-18): {"command":"pause","arguments":{"threadId":1},"type":"request","seq":18}
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (11075) <-1046-exec-interrupt\r\n"},"seq":920}

Other Extensions

No response

Additional Information

I see some relate issue in other soft page https://github.com/WebFreak001/code-debug/issues/186, it is the absolutly same with my wotk. It points to MIEngine https://github.com/microsoft/MIEngine/issues/844, but I do not know how it can fix my problem.

Start with the supplied launch.json and debugger trace, then compare the pause and step requests with the referenced MIEngine issue #844. Reproduce the configuration against the remote gdbserver and determine whether pause, stepping, and breakpoints work during execution; done means those controls operate reliably in the remote session.