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