Step causes GDB to spin in infinite loop when PC doesn't change
Luis Machado
luis.machado@arm.com
Fri Mar 18 17:46:58 GMT 2022
On 3/18/22 17:33, Denio, Mike wrote:
>>>>>
> That's what the step/next commands are designed to do. GDB will keep
> stepping until it sees a line change. I suppose a "continue" command
> here would be more appropriate, as GDB will send it once and keep
> waiting for the outcome. stepi/nexti would be undesirable given they
> will stop after a single instruction.
> <<<<
>
> Thanks that makes some level of sense. Stepi also works fine. It just seemed a little odd that the desired behavior would be to lock up GDB if a user accidentally did a "step" on a jump to $ instruction. You can't even get out with ^C. I had to kill the debug server to regain control of GDB.
I recall we used to have some issues like that, where GDB wouldn't stop
stepping and would give you enough time to ctrl-C your way out of it,
but they were fixed as far as I recall.
Are you using non-stop mode with synchronous commands? You might want to
try sending asynchronous commands (passing &), that way GDB will give
you the prompt instantly and you will have full control again. You can
then issue an interruption (interrupt -a) to stop everything.
More information about the Gdb
mailing list