I can trigger an internal error in 'finish_step_over()' using openocd on an ARM target running a ChibiOS demo. I'm using the ChibiOS rtos awareness in openocd which presents OS threads to GDB. The sequence is basically this: halt target, (gdb) info threads Id Target Id Frame * 1 Thread 536873944 (Name: idle, State: CURRENT) _idle_thread.lto_priv.87 (p=0x0) at ../../../os/rt/src/chsys.c:72 2 Thread 536876248 (Name: main, State: WTOREVT) chSchGoSleepTimeoutS (newstate=<optimized out>, timeout=<optimized out>) at ../../../os/rt/src/chschd.c:384 3 Thread 536873360 (Name: blinker 1, State: WTOREVT) chSchGoSleepTimeoutS (newstate=<optimized out>, timeout=<optimized out>) at ../../../os/rt/src/chschd.c:384 4 Thread 536873688 (Name: blinker 2, State: WTOREVT) chSchGoSleepTimeoutS (newstate=<optimized out>, timeout=<optimized out>) at ../../../os/rt/src/chschd.c:384 (gdb) thread 3 [Switching to thread 3 (Thread 536873360)] #0 chSchGoSleepTimeoutS (newstate=<optimized out>, timeout=<optimized out>) at ../../../os/rt/src/chschd.c:384 384 if (chVTIsArmedI(&vt)) { (gdb) b (gdb) c Continuing. infrun.c:5553: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) What seems to happen is that gdb assumes that changing the current thread inside gdb must be reflected on the target. If you set a breakpoint in frame 0 of the gdb-current thread, gdb performs a step-over on 'continue' and expects that the server actually steps this and this thread only. This is an assumption that can not hold. The server may not be able to influence the scheduler of the target so that the gdb-current thread is made current, and it also cannot force the gdb-current thread to become active without breaking assumptions of the underlying scheduler (i.e. a thread would become active when the scheduler doesn't expect it). What gdb should do is: - set the breakpoint at the appropriate frame in the gdb-current thread - _not_ issue a step-over - continue the target-current thread instead
Hi Matthias, could you "set debug remote 1", and post the log of remote packets here?
(gdb) info threads Id Target Id Frame 1 Thread 536876248 (Name: main, State: WTOREVT) chSchGoSleepTimeoutS (newstate=<optimized out>, timeout=<optimized out>) at ../../../os/rt/src/chschd.c:384 * 2 Thread 536873944 (Name: idle, State: CURRENT) _idle_thread.lto_priv.87 (p=0x0) at ../../../os/rt/src/chsys.c:72 3 Thread 536873360 (Name: blinker 1, State: WTOREVT) chSchGoSleepTimeoutS (newstate=<optimized out>, timeout=<optimized out>) at ../../../os/rt/src/chschd.c:384 4 Thread 536873688 (Name: blinker 2, State: WTOREVT) chSchGoSleepTimeoutS (newstate=<optimized out>, timeout=<optimized out>) at ../../../os/rt/src/chschd.c:384 (gdb) set debug remote 1 (gdb) thread 3 Sending packet: $T20000990#e8...Packet received: OK Sending packet: $T200014d8#17...Packet received: OK Sending packet: $T20000bd8#44...Packet received: OK Sending packet: $T20000990#e8...Packet received: OK Sending packet: $T20000ad8#43...Packet received: OK [Switching to thread 3 (Thread 536873360)] Sending packet: $Hg20000990#43...Packet received: OK Sending packet: $m8006dfc,4#c8...Packet received: 049b13b1 Sending packet: $m8006df8,4#9d...Packet received: fff712fe Sending packet: $m8006dfc,4#c8...Packet received: 049b13b1 Sending packet: $m8006df8,4#9d...Packet received: fff712fe Sending packet: $m8006dfc,2#c6...Packet received: 049b Sending packet: $m8006dfa,2#c4...Packet received: 12fe Sending packet: $m8006df8,2#9b...Packet received: fff7 Sending packet: $m8006dfc,2#c6...Packet received: 049b Sending packet: $m8006dfa,2#c4...Packet received: 12fe Sending packet: $m8006df8,2#9b...Packet received: fff7 Sending packet: $m8006dfc,4#c8...Packet received: 049b13b1 Sending packet: $m8006df8,4#9d...Packet received: fff712fe Sending packet: $m8006dfc,4#c8...Packet received: 049b13b1 Sending packet: $m8006df8,4#9d...Packet received: fff712fe Sending packet: $m8006dfc,4#c8...Packet received: 049b13b1 Sending packet: $m8006dfc,4#c8...Packet received: 049b13b1 Sending packet: $m8006dfc,4#c8...Packet received: 049b13b1 #0 chSchGoSleepTimeoutS (Sending packet: $m20000940,40#8c...Packet received: 0000000000000000000000000000000000000000fd6d000800000000a40a0020c4140020f40100008166000890090020000000000010004800000000716e0008 Sending packet: $m8006e70,4#67...Packet received: 002383f3 Sending packet: $m8006e6c,4#99...Packet received: fff7b8ff Sending packet: $m8006e70,4#67...Packet received: 002383f3 Sending packet: $m8006e6c,4#99...Packet received: fff7b8ff Sending packet: $m8006e70,2#65...Packet received: 0023 Sending packet: $m8006e6e,2#99...Packet received: b8ff Sending packet: $m8006e6c,2#97...Packet received: fff7 Sending packet: $m8006e70,2#65...Packet received: 0023 Sending packet: $m8006e6e,2#99...Packet received: b8ff Sending packet: $m8006e6c,2#97...Packet received: fff7 Sending packet: $m8006e70,4#67...Packet received: 002383f3 Sending packet: $m8006e6c,4#99...Packet received: fff7b8ff Sending packet: $m8006e70,4#67...Packet received: 002383f3 Sending packet: $m8006e6c,4#99...Packet received: fff7b8ff Sending packet: $m8006e70,4#67...Packet received: 002383f3 Sending packet: $m8006e70,4#67...Packet received: 002383f3 Sending packet: $m8006e70,4#67...Packet received: 002383f3 newstate=<optimized out>, timeout=<optimized out>) at ../../../os/rt/src/chschd.c:384 384 if (chVTIsArmedI(&vt)) { (gdb) b Sending packet: $m8006dc0,40#c2...Packet received: e8612862046044608160c7f834e03e61fa60f0bda8140020000000000000000030b54b1c87b012d00c4c0d4aa369054601a8fff7b5ff2846fff712fe049b13b1 Sending packet: $m8006dfc,2#c6...Packet received: 049b Sending packet: $m8006dfc,2#c6...Packet received: 049b Breakpoint 1 at 0x8006dfc: file ../../../os/rt/src/chschd.c, line 384. (gdb) c Continuing. Sending packet: $vCont?#49...Packet received: vCont;c;C;s;S Packet vCont (verbose-resume) is supported Sending packet: $vCont;s:20000990#86...Packet received: T05thread:0000000020000bd8; infrun.c:5553: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n)
I'm a little confused on this one. On the one hand -- the remote protocol doesn't have a way for a target to explain that it isn't in control of scheduling. This could be added, but only with some cooperation from gdb as well. However in the example you did: (gdb) b (gdb) c Doesn't that "b" set a breakpoint? Then "continue" has to step off the breakpoint. This is done by single-stepping, I suppose because setting another breakpoint is difficult -- gdb or gdbserver would have to decode instructions to find the next instruction.
I think this is a dup. The other bug mentions RISC-V, but if you read through it all (it's had a lot of comments, some patches, and been closed and reopened multiple times), in the end you'll see that the underlying issues have to do with OpenOCD and stepping generically. *** This bug has been marked as a duplicate of bug 26819 ***