public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Step causes GDB to spin in infinite loop when PC doesn't change
@ 2022-03-18 16:33 Denio, Mike
  2022-03-18 17:28 ` Luis Machado
  0 siblings, 1 reply; 7+ messages in thread
From: Denio, Mike @ 2022-03-18 16:33 UTC (permalink / raw)
  To: gdb

I am seeing an issue with the remote protocol  on GDB with multiple threads on a riscv32 using the step command. Not sure if it's a bug or just me, but it seems like a legitimate bug.

I am using a custom server. The behavior is the same on both GDB 11.1 and 11.2.

This GDB was configured as follows:
   configure --host=x86_64-pc-linux-gnu --target=riscv32-unknown-elf
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
             --without-libunwind-ia64
             --with-lzma
             --without-babeltrace
             --without-intel-pt
             --with-mpfr
             --without-xxhash
             --with-python=/usr
             --with-python-libdir=/usr/lib
             --without-debuginfod
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/local/lib/debug (relocatable)

I am running in non-stop mode. A full log of the test is at the end of the email. The GDB commands I execute after connecting are:
(gdb) interrupt -a
(gdb) s

The problem is that my code starts off in an infinite loop (endz: jal x0,endz), with the cores basically waiting for an interrupt. If I execute a 'step' command, GDB will basically keep sending "vCont;s:2" in an infinite loop, until the PC addr of thread 2 changes. It also occurs if I fall into an infinite loop while stepping. It doesn't need to be the first instruction.

Thanks,
Mike

---[ Remote Log ]------------------

(gdb) tar ext :9999
Remote debugging using :9999
[remote] start_remote: enter
  [remote] Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;memory-tagging+#ec
  [remote] Received Ack
  [remote] Packet received: hwbreak+;vContSupported+;QStartNoAckMode+;QNonStop+;PacketSize=410
  [remote] packet_ok: Packet qSupported (supported-packets) is supported
  [remote] Sending packet: $vMustReplyEmpty#3a
  [remote] Received Ack
  [remote] Packet received:
  [remote] Sending packet: $QStartNoAckMode#b0
  [remote] Received Ack
  [remote] Packet received: OK
  [remote] Sending packet: $!#21
  [remote] Packet received: OK
  [remote] Sending packet: $Hg0#df
  [remote] Packet received: OK
  [remote] Sending packet: $QNonStop:1#8d
  [remote] Packet received: OK
  [remote] Sending packet: $qfThreadInfo#bb
  [remote] Packet received: m1,2
  [remote] Sending packet: $qsThreadInfo#c8
  [remote] Packet received: l
  [remote] Sending packet: $qAttached#8f
  [remote] Packet received: 1
  [remote] packet_ok: Packet qAttached (query-attached) is supported
  [remote] Sending packet: $qTStatus#49
  [remote] Packet received:
  [remote] packet_ok: Packet qTStatus (trace-status) is NOT supported
  [remote] Sending packet: $?#3f
  [remote] Packet received: OK
  [remote] stop: enter
    [remote] Sending packet: $vCont?#49
    [remote] Packet received: vCont;c;C;s;t
    [remote] packet_ok: Packet vCont (verbose-resume) is supported
    [remote] Sending packet: $vCont;t:2#25
    [remote] Packet received: OK
  [remote] stop: exit
  [remote] Sending packet: $qSymbol::#5b
  [remote]   Notification received: Stop:T00thread:2;
  [remote] Packet received: OK
  [remote] packet_ok: Packet qSymbol (symbol-lookup) is supported
[remote] start_remote: exit
(gdb) [remote] wait: enter
  [remote] Sending packet: $vStopped#55
  [remote] Packet received: OK
[remote] wait: exit
[remote] Sending packet: $Hg2#e1
[remote] Packet received: OK
[remote] Sending packet: $g#67
[remote] Packet received: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
[remote] Sending packet: $qOffsets#4b
[remote] Packet received:
[remote] Sending packet: $qSymbol::#5b
[remote] Packet received: OK
[remote] wait: enter
[remote] wait: exit
[remote] Sending packet: $vCont;c#a8
[remote] Packet received: OK
[remote] wait: enter
[remote] wait: exit
interrupt -a
[remote] stop: enter
  [remote] Sending packet: $vCont;t#b9
  [remote] Packet received: OK
[remote] stop: exit
(gdb) [remote] wait: enter
  [remote]   Notification received: Stop:T00thread:1;
  [remote] Sending packet: $vStopped#55
  [remote] Packet received: T00thread:2;
  [remote] Sending packet: $vStopped#55
  [remote] Packet received: OK
[remote] wait: exit
[remote] Sending packet: $Hg1#e0
[remote] Packet received: OK
[remote] Sending packet: $g#67
[remote] Packet received: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
[remote] Sending packet: $qfThreadInfo#bb
[remote] Packet received: m1,2
[remote] Sending packet: $qsThreadInfo#c8
[remote] Packet received: l

Thread 1 stopped.
endz () at r5_tests/smoke/boot.S:8
8       endz: jal x0,endz
[remote] wait: enter
[remote] wait: exit
[remote] Sending packet: $Hg2#e1
[remote] Packet received: OK
[remote] Sending packet: $g#67
[remote] Packet received: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
[remote] Sending packet: $qfThreadInfo#bb
[remote] Packet received: m1,2
[remote] Sending packet: $qsThreadInfo#c8
[remote] Packet received: l

Thread 2 stopped.
endz () at r5_tests/smoke/boot.S:8
8       endz: jal x0,endz
[remote] wait: enter
[remote] wait: exit
s
[remote] Sending packet: $vCont;s:2#24
[remote] Packet received: OK
[remote] wait: enter
  [remote]   Notification received: Stop:T05thread:2;
  [remote] Sending packet: $vStopped#55
  [remote] Packet received: OK
[remote] wait: exit
[remote] Sending packet: $g#67
[remote] Packet received: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
[remote] wait: enter
[remote] wait: exit
[remote] Sending packet: $vCont;s:2#24
[remote] Packet received: OK
[remote] wait: enter
[remote] wait: exit
[remote] wait: enter
  [remote]   Notification received: Stop:T05thread:2;
  [remote] Sending packet: $vStopped#55
  [remote] Packet received: OK
[remote] wait: exit
[remote] Sending packet: $g#67
[remote] Packet received: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
[remote] wait: enter
[remote] wait: exit
[remote] Sending packet: $vCont;s:2#24
[remote] Packet received: OK
[remote] wait: enter
[remote] wait: exit
[remote] wait: enter
  [remote]   Notification received: Stop:T05thread:2;
  [remote] Sending packet: $vStopped#55
  [remote] Packet received: OK
[remote] wait: exit
[remote] Sending packet: $g#67
[remote] Packet received: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
[remote] wait: enter
[remote] wait: exit
[remote] Sending packet: $vCont;s:2#24
[remote] Packet received: OK
[remote] wait: enter
[remote] wait: exit
[remote] wait: enter
  [remote]   Notification received: Stop:T05thread:2;
  [remote] Sending packet: $vStopped#55
  [remote] Packet received: OK
[remote] wait: exit
[remote] Sending packet: $g#67
[remote] Packet received: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000
[remote] wait: enter
[remote] wait: exit
[remote] Sending packet: $vCont;s:2#24
[... and so on ...]





^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: Step causes GDB to spin in infinite loop when PC doesn't change
@ 2022-03-18 17:33 Denio, Mike
  2022-03-18 17:46 ` Luis Machado
  0 siblings, 1 reply; 7+ messages in thread
From: Denio, Mike @ 2022-03-18 17:33 UTC (permalink / raw)
  To: Luis Machado, gdb

>>>>
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.

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: Step causes GDB to spin in infinite loop when PC doesn't change
@ 2022-03-18 17:57 Denio, Mike
  2022-03-18 18:39 ` Pedro Alves
       [not found] ` <928a31c6f548411084f4a30dff48e1fe@ti.com>
  0 siblings, 2 replies; 7+ messages in thread
From: Denio, Mike @ 2022-03-18 17:57 UTC (permalink / raw)
  To: Luis Machado, 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.
<<<<

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?

I appreciate the feedback however, and I'll just tell users to be careful with the step command.

Mike


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-03-18 20:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-18 16:33 Step causes GDB to spin in infinite loop when PC doesn't change Denio, Mike
2022-03-18 17:28 ` Luis Machado
2022-03-18 17:33 Denio, Mike
2022-03-18 17:46 ` Luis Machado
2022-03-18 17:57 Denio, Mike
2022-03-18 18:39 ` Pedro Alves
     [not found] ` <928a31c6f548411084f4a30dff48e1fe@ti.com>
2022-03-18 20:57   ` Denio, Mike

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).