public inbox for
 help / color / mirror / Atom feed
From: Pedro Alves <>
To: "Denio, Mike" <>, Luis Machado <>,
	"" <>
Subject: Re: Step causes GDB to spin in infinite loop when PC doesn't change
Date: Fri, 18 Mar 2022 18:39:53 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2022-03-18 17:57, Denio, Mike via Gdb wrote:
> 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.
> <<<<
> Again, its not so much "what is the right command to use?" as it is "what happens if the user sends the wrong command?".
> I'm still new to this, but my interpretation of "step" was "step until the high level language instruction is complete, even if its multiple opcodes". This makes sense to me, to step over C instructions or multi opcode pseudo ops. The interpretation of "step" that makes less sense to me is "keep calling step until the PC changes", because if the PC didn't change after the first step, why would it ever change?

"step" is defined as

 (gdb) help step
 Step program until it reaches a different source line.

If the program has a loop that never reaches a different line, GDB will happily continue stepping.
Nothing wrong with that.  Could be spinlock, for example, waiting on some external condition, interrupt,

Now, if Ctrl-C doesn't work, then that's a bug somewhere.

  reply	other threads:[~2022-03-18 18:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-18 17:57 Denio, Mike
2022-03-18 18:39 ` Pedro Alves [this message]
     [not found] ` <>
2022-03-18 20:57   ` Denio, Mike
  -- strict thread matches above, loose matches on Subject: below --
2022-03-18 17:33 Denio, Mike
2022-03-18 17:46 ` Luis Machado
2022-03-18 16:33 Denio, Mike
2022-03-18 17:28 ` Luis Machado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).