You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Debugging: Unable to halt execution using arm gdb #833
Setup launch.json to use arm-none-eabi-gdb for debugging a c program on an embedded target (see attached launch.txt)
Set one breakpoint to beginning of main
Start debug session
Breakpoint in main fires. Press "play" button to continue
Try to halt the target by pressing "pause"
The result is that nothing happens. Any attempt to use the debug console results is
"Unable to perform this action because the process is running."
The way to halt the execution when using command line arm-none-eabi-gdb is to press ctrl-c (SIGINT?). Could this option be added to vscode debugger config?
For me, execution halts on a breakpoint at the beginning of main regardless of "stopAtEntry" value. I can add multiple breakpoints while the target is halted and they all work. It's just that I cannot halt with the pause button or add new breakpoints anymore while it's running. I would need a way to send ctrl+c to the arm-none-eabi-gdb process.
My gcc options: -mcpu=cortex-m3 -mthumb -fmessage-length=0 -ffunction-sections -fdata-sections -std=c11 -Og -g3 -flto launch.json.txt
And I have absolutely same reaction on trying to halt or add breakpoint while programs is running.
But if I connect to openocd via telnet, I can halting program by halt command.
Timur Taipov (@timurey)am1ko Can either of you try and run -exec -gdb-set target-async off in the Debug Console when you are stopped and see if the breakpoints are responsive? I'm hearing that some of versions of gdb are not handling this correctly.
-exec -gdb-set target-async off
1: (8106) <-1018-gdb-set target-async off
1: (8106) ->1018^error,msg="Cannot change this setting while the inferior is running."
1: (8106) ->(gdb)
1: (8106) 1018: elapsed time 0
result-class: error
msg: Cannot change this setting while the inferior is running.
vscode version 1.15.1 (1.15.1)
arm-none-eabi-gcc version 6.3.1 20170620
After updating vscode and gcc I now see debug output when trying to break. Still does not work though
C pause: {"threadId":57005}
R: {"success":true,"message":null,"request_seq":23,"command":"pause","body":null,"running":false,"refs":null,"seq":0,"type":"response"}
C evaluate: {"expression":"-exec -gdb-set target-async off","frameId":1000,"context":"repl"}
1: (34420) <-1092-gdb-set target-async off
1: (34421) ->1092^error,msg="Cannot change this setting while the inferior is running."
1: (34421) ->(gdb)
1: (34421) 1092: elapsed time 0
E output: {"category":"stdout","output":"result-class: error\r\nmsg: Cannot change this setting while the inferior is running.\r\n\n","data":null,"type":"output"}
result-class: error
msg: Cannot change this setting while the inferior is running.
Did you try using "hardware breakpoint" instead of "software breakpoint" ?
"HW breakpoint" the only solution i found to debug on a STM32F746 evaluation board . i suppose the "SW breakpoint" not enough when the code is executed from the flash memory.
I have confirmed (by adding some logging, can't get remote debugging of MIDebug working yet) that IsLocalGDB() == true (as expected), 42000 is the debuggeePid value (not sure where it comes from, but it is always the same on every launch), useSignal == true, and CmdBreakUnix is sending interrupt to pid 42000 instead of sending it to transport.DebuggerPid().
With this change it does work on Mac (haven't tested on Linux, assume it's also going to work). I assume that the proper change would be to introduce a new option, remote, and decide which PID to interrupt based on that. One more place where this option needs to be checked is when debuggee is started. For remote target, gdb can't use run, and continue should be used instead.
However going back to Windows, I can't get a breakpoint in CmdBreakInternal to get hit, when I press the 'pause' button in VS Code. (Breakpoints in various initialisation functions do get hit.)
What would be a good way to trace whether VS Code is actually sending anything to MIDebug when I press the 'pause' button?
I also had some difficulty getting 'pause' to work in a remote gdb/gdbserver session. For me, the key was to set MIDebuggerServerAddress to the ip address:port of the gdb server. Without that, everything works fine except pausing the running target.
Quoting am1ko:
"Setup launch.json to use arm-none-eabi-gdb for debugging a c program on an embedded target (see attached launch.txt)
Set one breakpoint to beginning of main
Start debug session
Breakpoint in main fires. Press "play" button to continue
Try to halt the target by pressing "pause"
The result is that nothing happens. "
One addition is that trying to stop the target after pressing "play" with no other breakpoints set does not work.
I can kill the gdb process with the pid, and sending a kill -2 works. See launch.json below.
Activity
weinand commentedon Jun 18, 2017
From Timur Taipov (@timurey) on June 18, 2017 18:30
Have the same issue.
pieandcakes commentedon Jun 19, 2017
am1ko Timur Taipov (@timurey) If you set "stopAtEntry" to true does it stop? Did you compile with the
-gflag?am1ko commentedon Jun 19, 2017
I just tried "stopAtEntry" and it seems to have no effect whatsoever.
I am compiling with -g flag. Here are the compiler flags I use:
arm-none-eabi-gcc -x assembler-with-cpp -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-sp-d16 -mfloat-abi=hard -O0 -Wall -fdata-sections -ffunction-sections -g -gdwarf-2
For me, execution halts on a breakpoint at the beginning of main regardless of "stopAtEntry" value. I can add multiple breakpoints while the target is halted and they all work. It's just that I cannot halt with the pause button or add new breakpoints anymore while it's running. I would need a way to send ctrl+c to the arm-none-eabi-gdb process.
pieandcakes commentedon Jun 19, 2017
am1ko Can you enable
"logging" : { "trace": true, "traceResponse": true, "engineLogging": true }and retry your scenario and send me the log?I have seen issues in GDB where it won't allow us to set breakpoints while running in MI mode.
am1ko commentedon Jun 19, 2017
launch copy.json.txt
am1ko commentedon Jun 19, 2017
debug_log.txt
am1ko commentedon Jun 19, 2017
Pierson Lee (@pieandcakes) logs attached
I tried to halt and add breakpoints from vscode when recording the log but I see no log entries written at those times.
The breakpoint you see being hit is something that I trigger by controlling the ui of the program being debugged.
timurey commentedon Jun 20, 2017
My gcc options:
-mcpu=cortex-m3 -mthumb -fmessage-length=0 -ffunction-sections -fdata-sections -std=c11 -Og -g3 -fltolaunch.json.txt
And I have absolutely same reaction on trying to halt or add breakpoint while programs is running.
But if I connect to openocd via telnet, I can halting program by
haltcommand.pieandcakes commentedon Jun 29, 2017
Timur Taipov (@timurey) am1ko Can either of you try and run
-exec -gdb-set target-async offin the Debug Console when you are stopped and see if the breakpoints are responsive? I'm hearing that some of versions of gdb are not handling this correctly.timurey commentedon Jun 30, 2017
Result:
in telnet console:
But still can't halt running or add breakpoint.
am1ko commentedon Aug 22, 2017
vscode version 1.15.1 (1.15.1)
arm-none-eabi-gcc version 6.3.1 20170620
After updating vscode and gcc I now see debug output when trying to break. Still does not work though
C pause: {"threadId":57005}
R: {"success":true,"message":null,"request_seq":23,"command":"pause","body":null,"running":false,"refs":null,"seq":0,"type":"response"}
am1ko commentedon Aug 22, 2017
Pierson Lee (@pieandcakes)
Tried your suggestion. Same result as Timur Taipov (@timurey)
C evaluate: {"expression":"-exec -gdb-set target-async off","frameId":1000,"context":"repl"}
1: (34420) <-1092-gdb-set target-async off
1: (34421) ->1092^error,msg="Cannot change this setting while the inferior is running."
1: (34421) ->(gdb)
1: (34421) 1092: elapsed time 0
E output: {"category":"stdout","output":"result-class: error\r\nmsg: Cannot change this setting while the inferior is running.\r\n\n","data":null,"type":"output"}
result-class: error
msg: Cannot change this setting while the inferior is running.
am1ko commentedon Aug 22, 2017
If I do
"setupCommands": [
{
"text": "set target-async off"
},
I can break the execution successfully form bash by sending SIGINT to the gdb process
kill -2 31276
vscode pause button still doesn't work.
chrisfou commentedon Dec 2, 2017
Did you try using "hardware breakpoint" instead of "software breakpoint" ?
"HW breakpoint" the only solution i found to debug on a STM32F746 evaluation board . i suppose the "SW breakpoint" not enough when the code is executed from the flash memory.
36 remaining items
igrr commentedon Nov 12, 2018
I have confirmed (by adding some logging, can't get remote debugging of MIDebug working yet) that
IsLocalGDB() == true(as expected), 42000 is thedebuggeePidvalue (not sure where it comes from, but it is always the same on every launch),useSignal == true, andCmdBreakUnixis sending interrupt to pid 42000 instead of sending it totransport.DebuggerPid().Edit: 42000 is the magic value which GDB uses as the PID if the remote target does not support multiprocess extensions and sends only the thread id (https://github.com/bminor/binutils-gdb/blob/417e50dbcfd4b8dd699f48df5ac9b9a733fd80e2/gdb/remote.c#L14834-L14836)
pieandcakes commentedon Nov 12, 2018
Ivan Grokhotkov (@igrr) Thank you for investigating.
if you change Debugger.cs:715 to be the following:
and try your scenario with the updated bits, can you confirm it works?
igrr commentedon Nov 13, 2018
With this change it does work on Mac (haven't tested on Linux, assume it's also going to work). I assume that the proper change would be to introduce a new option,
remote, and decide which PID to interrupt based on that. One more place where this option needs to be checked is when debuggee is started. For remote target, gdb can't userun, andcontinueshould be used instead.However going back to Windows, I can't get a breakpoint in CmdBreakInternal to get hit, when I press the 'pause' button in VS Code. (Breakpoints in various initialisation functions do get hit.)
What would be a good way to trace whether VS Code is actually sending anything to MIDebug when I press the 'pause' button?
igrr commentedon Jul 4, 2019
It seems that this is fixed by microsoft/MIEngine@ecc1b0e.
sean-mcmanus commentedon Jul 6, 2019
Ivan Grokhotkov (@igrr) So it's fixed with 0.24.0? It has an updated MIEngine.
dcrivelli commentedon Jan 23, 2020
This seems not yet working either with VS2017 (15.9.19) and VS2019 (16.4.3). Still have to pause through 'kill -2'.
pieandcakes commentedon Jan 23, 2020
dcrivelli this is for the extension for VS Code, not VS.
Please open a detailed issue for your scenario on https://github.com/microsoft/miengine with repro steps and i'll look into it.
heartacker commentedon Aug 17, 2020
hi. any update? I have the same problem
stansotn commentedon Oct 22, 2020
I am having the same problem with embedded ARM. More details in #807
dachalco commentedon Feb 2, 2021
I'm using a different compiler but having the same issue. Remote target is halted but VSCode interface not synced with remote target.
BillPlunkett commentedon Mar 25, 2021
I also had some difficulty getting 'pause' to work in a remote gdb/gdbserver session. For me, the key was to set MIDebuggerServerAddress to the ip address:port of the gdb server. Without that, everything works fine except pausing the running target.
brianhindman commentedon May 27, 2021
VSCode Version: 1.56.2
OS Version: MacOS Big Sur 11.2.3
arm-none-eabi-gcc version: 6.3.1
arm-none-eabi-gdb version: 7.12.1
Steps to Reproduce (same as am1ko):
Quoting am1ko:
"Setup launch.json to use arm-none-eabi-gdb for debugging a c program on an embedded target (see attached launch.txt)
Set one breakpoint to beginning of main
Start debug session
Breakpoint in main fires. Press "play" button to continue
Try to halt the target by pressing "pause"
The result is that nothing happens. "
One addition is that trying to stop the target after pressing "play" with no other breakpoints set does not work.
I can kill the gdb process with the pid, and sending a kill -2 works. See launch.json below.
launch-json.txt
fbs2016 commentedon Sep 1, 2021
I meet the same issue, see details #7719 Unable to set breakpoint or pause on a running application with extended-remote connection debug
Re-do launch configuration to use cpptools built-in remote config