[Bug breakpoints/30215] New: GDB cannot hit second time in empty while loop

[Bug breakpoints/30215] New: GDB cannot hit second time in empty while loop

[ahmet_kcbyk at hotmail dot com]

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

            Bug ID: 30215
           Summary: GDB cannot hit second time in empty while loop
           Product: gdb
           Version: 12.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: ahmet_kcbyk at hotmail dot com
  Target Milestone: ---

This report describes a problem encountered when using GDB 12.1 to debug a C
program compiled with x86-64 11.2 gcc and the following flags: -O0 -g -gdwarf-2
-Wall -c -fmessage-length=0 -nostdinc -fno-builtin -finput-charset=Cp1252
-fcommon. 
The problem occurs when setting a breakpoint at the beginning of an empty while
loop that contains three assembly instructions: first a nop, then a compare and
a jump. The breakpoint is hit only once at the first iteration of the loop, but
not at subsequent iterations because the compare-jump block skips over the nop
instruction where the breakpoint is set. This makes it difficult to debug the
loop behavior using GDB breakpoints. 
We used Eclipse 2022-12 in Ubuntu 2022.04.1 5.19.0-32-generic linux kernel.
Here is an example code that generates the situation, the breakpoint must be
placed on the while loop. Breakpoint only hits once.

#include <stdio.h>

void foo(void) 
{
int a = 1;
while(a);
}

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

[Bug breakpoints/30215] GDB cannot hit second time in empty while loop

[ahmet_kcbyk at hotmail dot com]

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

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.

[Bug breakpoints/30215] GDB cannot hit second time in empty while loop

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
The Fedora 36 gcc has this issue.
Look at my source and the decodedline dump:

murgatroyd. nl -ba q.c
     1  void foo(void) 
     2  {
     3  int a = 1;
     4  while(a);
     5  }
murgatroyd. readelf --debug-dump=decodedline q.o 
Contents of the .debug_line section:

CU: ./q.c:
File name                            Line number    Starting address    View   
Stmt
q.c                                            2                   0           
   x
q.c                                            3                 0x4           
   x
q.c                                            4                 0xb           
   x
q.c                                            4                 0xc           
   x
q.c                                            5                0x12           
   x
q.c                                            -                0x16


Now the disassembly:

0000000000000000 <foo>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   c7 45 fc 01 00 00 00    movl   $0x1,-0x4(%rbp)
   b:   90                      nop
   c:   83 7d fc 00             cmpl   $0x0,-0x4(%rbp)
  10:   75 fa                   jne    c <foo+0xc>
...

Both 0xb and 0xc are marked as statements.
However when setting a breakpoint, I think gdb picks the lowest address.

So on the one hand, maybe this is a gdb bug.
Perhaps it should set a low-level breakpoint at each instruction that is
marked as being a statement at the given line.  The idea being, if a given
statement has multiple "entry points", gdb should catch them all.  These
would have to be spots where stepping would stop as well.

On the other hand, IMO this behavior by the compiler is pathological.

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

[Bug breakpoints/30215] GDB cannot hit second time in empty while loop

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #2 from Hannes Domani <ssbssa at sourceware dot org> ---
Seems similar to the issue of this question:
https://stackoverflow.com/questions/75333490/gdb-breakpoint-not-hit

Simplified code:

int main(int argc, char **argv)
{
  int ret;

  while (1)
  {
    if (argc > 3)
      ret = 1;
    else if (argc > 2)
      ret = 2;
    else
      ret = 3;
    break; // BREAKPOINT
  }

  return ret;
}

It will hit the breakpoint only if the first if-condition is fulfilled, even
though there are 3 locations in the line-table for line 13:

INDEX  LINE   ADDRESS            IS-STMT
0      2      0x000000013ffd1600 Y
1      2      0x000000013ffd160f Y
2      7      0x000000013ffd1614 Y
3      8      0x000000013ffd161a Y
4      13     0x000000013ffd1621 Y
5      9      0x000000013ffd1623 Y
6      10     0x000000013ffd1629 Y
7      13     0x000000013ffd1630 Y
8      12     0x000000013ffd1632 Y
9      13     0x000000013ffd1639 Y
10     16     0x000000013ffd163a Y
11     17     0x000000013ffd163d Y
12     END    0x000000013ffd1643 Y

   0x000000013ffd1600 <+0>:     push   %rbp
   0x000000013ffd1601 <+1>:     mov    %rsp,%rbp
   0x000000013ffd1604 <+4>:     sub    $0x30,%rsp
   0x000000013ffd1608 <+8>:     mov    %ecx,0x10(%rbp)
   0x000000013ffd160b <+11>:    mov    %rdx,0x18(%rbp)
   0x000000013ffd160f <+15>:    call   0x13ffd1700 <__main>
   0x000000013ffd1614 <+20>:    cmpl   $0x3,0x10(%rbp)
   0x000000013ffd1618 <+24>:    jle    0x13ffd1623 <main+35>
   0x000000013ffd161a <+26>:    movl   $0x1,-0x4(%rbp)
   0x000000013ffd1621 <+33>:    jmp    0x13ffd1639 <main+57>
   0x000000013ffd1623 <+35>:    cmpl   $0x2,0x10(%rbp)
   0x000000013ffd1627 <+39>:    jle    0x13ffd1632 <main+50>
   0x000000013ffd1629 <+41>:    movl   $0x2,-0x4(%rbp)
   0x000000013ffd1630 <+48>:    jmp    0x13ffd1639 <main+57>
   0x000000013ffd1632 <+50>:    movl   $0x3,-0x4(%rbp)
   0x000000013ffd1639 <+57>:    nop
   0x000000013ffd163a <+58>:    mov    -0x4(%rbp),%eax
   0x000000013ffd163d <+61>:    add    $0x30,%rsp
   0x000000013ffd1641 <+65>:    pop    %rbp
   0x000000013ffd1642 <+66>:    ret

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