[Bug gdb/21221] gdb hangs while stepping an empty loop

[Bug gdb/21221] gdb hangs while stepping an empty loop

[luis.machado at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

Luis Machado <luis.machado at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|luis.machado at linaro dot org     |unassigned at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[luis.machado at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #10 from Luis Machado <luis.machado at linaro dot org> ---
This patch series could improve things by considering column information.

https://sourceware.org/pipermail/gdb-patches/2020-May/168673.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[darius at dons dot net.au]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

Daniel O'Connor <darius at dons dot net.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darius at dons dot net.au

--- Comment #11 from Daniel O'Connor <darius at dons dot net.au> ---
I just ran into this issue recently using a Black Magic probe to debug an STM32
and I think it is also a GDB bug.

When this is triggered you have to kill GDB because ctrl-c does not interrupt
it.

See this bug report: https://github.com/blackmagic-debug/blackmagic/issues/190

Notably GDB is not hung, nor is the BMP probe - GDB is simply stuck in a loop
talking to the BMP setting breakpoints etc.

I don't really know where to start looking in the GDB code to see why it blocks
being interrupted though so it's hard to see how difficult it would be to
mitigate the problem.

Obviously with the 'nop' work around it's not a big deal but it was quite a
frustrating experience until I learnt that :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #12 from Luis Machado <luis.machado at arm dot com> ---
GDB should always acknowledge an interrupt request, so that is clearly a bug.
I'm not sure if it should be handled in this particular ticket though.

It is related to this ticket, but it seems to be a different issue. Maybe one
involving the remote target advertising the proper features so GDB can properly
communicate the ctrl-c sequence.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[darius at dons dot net.au]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #13 from Daniel O'Connor <darius at dons dot net.au> ---
I don't think this is an issue with the remote target / GDB communication since
the trace shows GDB is still issuing commands rather than waiting for
something.

I'm happy to open a new bug for GDB not being interruptible in this situation,
although I think in that case this bug would be closed because it doesn't cover
anything (since all that would be left is the GCC side which looks like is
handled in a different bug system)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[kristof.mulier at telenet dot be]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

kristof mulier <kristof.mulier at telenet dot be> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kristof.mulier at telenet dot be

--- Comment #14 from kristof mulier <kristof.mulier at telenet dot be> ---
We use GDB as our debugger backend in "Embeetle IDE" (a new IDE for
microcontroller coding, we developed it from scratch, it's not based on Eclipse
or any other existing IDE).
Unfortunately, this "GDB hangs while stepping an empty loop" bug is blocking
our progress considerably. I'm looking for someone who can fix this bug in
return for a payment/donation. Please contact me. My name is Kristof Mulier.
You can find my contact info on the "Embeetle IDE" website.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #15 from Luis Machado <luis.machado at arm dot com> ---
Do you have a case of a 1 line loop that debuggers get stuck on?

Are you seeing this mostly with gcc or clang as well?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[kristof.mulier at telenet dot be]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #16 from kristof mulier <kristof.mulier at telenet dot be> ---
Hi @Luis,
Thanks for your quick reply!
We have this problem with GCC, that's what we are using. Here is an example of
the loop code:

    void delay_1ms(uint32_t count)
    {
        delay = count;

        while(0U != delay){
        } // <- this loop causes the problem
    }

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #17 from Luis Machado <luis.machado at arm dot com> ---
(In reply to kristof mulier from comment #16)
> Hi @Luis,
> Thanks for your quick reply!
> We have this problem with GCC, that's what we are using. Here is an example
> of the loop code:
> 
>     void delay_1ms(uint32_t count)
>     {
>         delay = count;
> 
>         while(0U != delay){
>         } // <- this loop causes the problem
>     }

Right. That while case *should* be a case where we can handle things in a sane
way if there are more than a single instruction. I believe clang might generate
code that doesn't cause gdb to get stuck.

gcc is a different matter though. Last time I was investigating this, gcc used
to get rid of opening/closing brace line entries, whereas clang doesn't. The
opening/closing brace is something compilers can use to generate a line entry,
which gdb would like to see for a step/next command.

Handling these cases (they are a set of multiple corner cases depending on how
you write your code) in gdb is not trivial unfortunately.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[kristof.mulier at telenet dot be]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #18 from kristof mulier <kristof.mulier at telenet dot be> ---
> Handling these cases (they are a set of multiple corner cases depending on how you write your code) in gdb is not trivial unfortunately.

Indeed, we understand this is a very complicated problem to solve.

> I believe clang might generate code that doesn't cause GDB to get stuck.

Unfortunately, we need a solution that's independent of the compiler. We cannot
force our users to use Clang.

Do you think a solution would be possible, that works for the current GCC
versions? Or is this a fundamental problem?

Many microcontroller sample projects use these kinds of empty loops for delays.
If you stop the program, there's always a big probability the PC is in such a
loop. So, this "GDB hangs while stepping an empty loop" issue is really
important to many GDB users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #19 from Luis Machado <luis.machado at arm dot com> ---
When it happens, can you actually interrupt it so you regain control of gdb?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[darius at dons dot net.au]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #20 from Daniel O'Connor <darius at dons dot net.au> ---
(In reply to Luis Machado from comment #19)
> When it happens, can you actually interrupt it so you regain control of gdb?

No, it's stuck sending this to the remote debugger:
Breakpoint 1, i2c_write7_v1 (i2c=1073763328, addr=80, data=0x2001ffa4 "", n=2,
start=true) at hal.c:62
62          if (start) {
(gdb) next
63              for (tout = I2C_TIMEOUT; tout > 0 && (I2C_SR2(i2c) &
I2C_SR2_BUSY); tout--)
(gdb) set debug remote 1
(gdb) next
[remote] Sending packet: $Z1,8000546,2#7c
[remote] Received Ack
[remote] Packet received: OK
[remote] Sending packet: $m800054e,2#61
[remote] Received Ack
[remote] Packet received: 404b
[remote] Sending packet: $m800054e,2#61
[remote] Received Ack
[remote] Packet received: 404b
[remote] Sending packet: $m8000550,2#2d
[remote] Received Ack
[remote] Packet received: 7b61
[remote] Sending packet: $m800054e,4#63
[remote] Received Ack
[remote] Packet received: 404b7b61
[remote] Sending packet: $m800054e,2#61
[remote] Received Ack
[remote] Packet received: 404b
[remote] Sending packet: $m800054e,2#61
[remote] Received Ack
[remote] Packet received: 404b
[remote] Sending packet: $Z1,8000550,2#77
[remote] Received Ack
[remote] Packet received: OK
[remote] Sending packet: $c#63
[remote] Received Ack
[remote] wait: enter
[remote] wait: exit
[remote] wait: enter
  [remote] Packet received: T05
  [remote] select_thread_for_ambiguous_stop_reply: enter
    [remote] select_thread_for_ambiguous_stop_reply: process_wide_stop = 0
    [remote] select_thread_for_ambiguous_stop_reply: first resumed thread is
Thread 1
    [remote] select_thread_for_ambiguous_stop_reply: is this guess ambiguous? =
0
  [remote] select_thread_for_ambiguous_stop_reply: exit
[remote] wait: exit

(See
https://github.com/blackmagic-debug/blackmagic/issues/190#issuecomment-1327190470)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

--- Comment #21 from Luis Machado <luis.machado at arm dot com> ---
Thanks for the input. That behavior sounds like a different bug in gdb. When in
motion, gdb should always be interruptible so that you don't run into
situations like this.

There isn't much gdb can do about the tight loops themselves, but there should
be a graceful way out of it with the interruption.

In the past there used to be a race condition between gdb sending the interrupt
request and the remote replying with a stop reply, and then gdb for some reason
used to disregard the interrupt request and proceed with the motion (issuing
stepi/continue over and over again).

I'll have to play with this a bit more to see if I can reproduce the same
situation.

Unrelated, but I did notice the black magic debugging stub is still using ACK
packets though. If it isn't dealing with unreliable communication channels,
that can be dropped.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedro at palves dot net

--- Comment #22 from Pedro Alves <pedro at palves dot net> ---
IME, this issue of ctrl-c-not-interrupting-tight-loop is most often caused by
the stub itself not handling the interrupt request properly.  Typically, gdb
sends the interrupt "packet" (\003), and but the stub reports a SIGTRAP stop
instead of a SIGINT stop, because of single-stepping or hitting a breakpoint,
and the interrupt request ends up lost.

So I'd start by confirming whether gdb did send the \003 over the wire, and
then checking whether the stub ended up dropping it for a reason similar to
what I mentioned.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/21221] gdb hangs while stepping an empty loop

[ahmet_kcbyk at hotmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21221

Ahmet Muhammet KOCABIYIK <ahmet_kcbyk at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahmet_kcbyk at hotmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.