[Bug gdb/31849] New: Issue with Unexpected Behavior in GDB Stepping at Optimization Level O2 and O3

[Bug gdb/31849] New: Issue with Unexpected Behavior in GDB Stepping at Optimization Level O2 and O3

[iamanonymous.cs at gmail dot com]

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

            Bug ID: 31849
           Summary: Issue with Unexpected Behavior in GDB Stepping at
                    Optimization Level O2 and O3
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

The gdb and gcc versions are as follows: 

$ gcc --version
gcc (GCC) 15.0.0 20240509 (experimental)

$ gdb --version
GNU gdb (GDB) 15.0.50.20240512-git


$ gcc -O2 -g small.c
$ gdb a.out -q
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401060: file small.c, line 43.
(gdb) r
Starting program: /root/a.out 

Breakpoint 1, main () at small.c:43
43        asm volatile ("" : "+r" (x));
(gdb) s
44        foo (x);
(gdb) s
foo (x=1) at small.c:19
19        if (x == 0)
(gdb) s
25        else if (x == 1)
(gdb) s
17      foo (int x)
(gdb) s
foo (x=1) at small.c:28
28            int *b = __builtin_malloc (3 * sizeof (int));
(gdb) 

##################################
When using GDB to debug the program compiled at optimization level O2 or O3,
the expected behavior is that when the execution is stopped at line #25,
stepping forward with the 'step' command should advance the execution to the
next line. However, it has been observed that the program unexpectedly stops at
line #17 instead.
##################################

##################################
Here is the source code that can reproduce this problem. 

$ cat small.c

__attribute__((noinline, noclone)) void
bar (int *b)
{
  b[0] = b[1] = b[2] = 1;
}

__attribute__((noinline, noclone)) int
baz (int x)
{
  if (x != 1)
    __builtin_abort ();
}

void 
foo (int x)
{
  if (x == 0)
    {
      int *b = __builtin_malloc (3 * sizeof (int));
      while (b[0])
        ;
    }
  else if (x == 1)
    {
      int i, j;
      int *b = __builtin_malloc (3 * sizeof (int));
      for (i = 0; i < 2; i++)
        {
          bar (b);
          for (j = 0; j < 3; ++j)
            baz (b[j]);
          baz (b[0]);
        }
    }
}

int
main ()
{
  int x = 1;
  asm volatile ("" : "+r" (x));
  foo (x);
  return 0;
}

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

[Bug gdb/31849] Issue with Unexpected Behavior in GDB Stepping at Optimization Level O2 and O3

[iamanonymous.cs at gmail dot com]

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

Anonymous <iamanonymous.cs at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iamanonymous.cs at gmail dot com,
                   |                            |tromey at sourceware dot org

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

[Bug gdb/31849] Issue with Unexpected Behavior in GDB Stepping at Optimization Level O2 and O3

[iamanonymous.cs at gmail dot com]

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

--- Comment #1 from Anonymous <iamanonymous.cs at gmail dot com> ---
Additionally, this unexpected stepping behavior does not occur when the program
is compiled with optimization level O0.

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

[Bug gdb/31849] Issue with Unexpected Behavior in GDB Stepping at Optimization Level O2 and O3

[iamanonymous.cs at gmail dot com]

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

--- Comment #2 from Anonymous <iamanonymous.cs at gmail dot com> ---
(In reply to Anonymous from comment #1)
> Additionally, this unexpected stepping behavior does not occur when the
> program is compiled with optimization level O0.

We found this issue by comparing the executable files compiled with
optimization level O2, when comparing the debugging traces at the source level
and the instruction level.

We know that since optimization will optimize a large amount of code, the hit
information (i.e., the lines of code that the debugger stops at) of executable
files generated with different optimization levels under GDB cannot be directly
compared.

Here, "this unexpected stepping behavior does not occur" indicates that, at the
O0 level, neither the source-level debugging nor the instruction-level
debugging encountered the unexpected stopping at line #17.

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

[Bug gdb/31849] Issue with Unexpected Behavior in GDB Stepping at Optimization Level O2 and O3

[tromey at sourceware dot org]

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

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
You should probably attach your executable, since this is
most likely compiler dependent.

One suggestion is to examine the line table and see what it says.
Often this kind of behavior ends up being gdb doing what the
compiler said to do.

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

[Bug gdb/31849] Issue with Unexpected Behavior in GDB Stepping at Optimization Level O2 and O3

[iamanonymous.cs at gmail dot com]

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

--- Comment #4 from Anonymous <iamanonymous.cs at gmail dot com> ---
Created attachment 15571
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15571&action=edit
the triggering binary

Line 15 has debug info. the 'IS-STMT' flag is Y (yes). 
(gdb) > maint info line-table small.c

linetable: ((struct linetable *) 0x12b9f40):
INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END
EPILOGUE-BEGIN 
0      11     0x0000000000401050 0x0000000000401050 Y                           
1      9      0x0000000000401050 0x0000000000401050                             
2      11     0x0000000000401051 0x0000000000401051                             
3      END    0x0000000000401056 0x0000000000401056 Y                           
4      39     0x0000000000401060 0x0000000000401060 Y                           
5      40     0x0000000000401060 0x0000000000401060 Y                           
6      41     0x0000000000401060 0x0000000000401060 Y                           
7      39     0x0000000000401060 0x0000000000401060                             
8      41     0x0000000000401064 0x0000000000401064                             
9      42     0x0000000000401069 0x0000000000401069 Y                           
10     43     0x000000000040106e 0x000000000040106e Y                           
11     44     0x000000000040106e 0x000000000040106e                             
12     END    0x0000000000401075 0x0000000000401075 Y                           
13     3      0x0000000000401170 0x0000000000401170 Y                           
14     4      0x0000000000401170 0x0000000000401170 Y                           
15     4      0x0000000000401170 0x0000000000401170                             
16     4      0x0000000000401177 0x0000000000401177                             
17     4      0x000000000040117e 0x000000000040117e                             
18     5      0x0000000000401181 0x0000000000401181                             
19     9      0x0000000000401190 0x0000000000401190 Y                           
20     10     0x0000000000401190 0x0000000000401190 Y                           
21     10     0x0000000000401190 0x0000000000401190                             
22     16     0x00000000004011a0 0x00000000004011a0 Y                           
23     17     0x00000000004011a0 0x00000000004011a0 Y                           
24     16     0x00000000004011a0 0x00000000004011a0                             
25     17     0x00000000004011a4 0x00000000004011a4                             
26     23     0x00000000004011a8 0x00000000004011a8 Y                           
27     23     0x00000000004011a8 0x00000000004011a8                             
28     35     0x00000000004011ad 0x00000000004011ad                             
29     19     0x00000000004011b8 0x00000000004011b8 Y                           
30     19     0x00000000004011b8 0x00000000004011b8                             
31     19     0x00000000004011bd 0x00000000004011bd                             
32     20     0x00000000004011c2 0x00000000004011c2 Y                           
33     15     0x00000000004011d0 0x00000000004011d0 Y                           
34     25     0x00000000004011d0 0x00000000004011d0 Y                           
35     26     0x00000000004011d0 0x00000000004011d0 Y                           
36     26     0x00000000004011d0 0x00000000004011d0                             
37     26     0x00000000004011d5 0x00000000004011d5                             
38     27     0x00000000004011e3 0x00000000004011e3 Y                           
39     29     0x00000000004011e3 0x00000000004011e3 Y                           
40     30     0x00000000004011eb 0x00000000004011eb Y                           
41     31     0x00000000004011eb 0x00000000004011eb Y                           
42     30     0x00000000004011f4 0x00000000004011f4 Y                           
43     31     0x00000000004011f4 0x00000000004011f4 Y                           
44     30     0x00000000004011fc 0x00000000004011fc Y                           
45     31     0x00000000004011fc 0x00000000004011fc Y                           
46     30     0x0000000000401204 0x0000000000401204 Y                           
47     32     0x0000000000401204 0x0000000000401204 Y                           
48     27     0x000000000040120b 0x000000000040120b Y                           
49     END    0x0000000000401219 0x0000000000401219 Y

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

[Bug gdb/31849] Issue with Unexpected Behavior in GDB Stepping at Optimization Level O2 and O3

[iamanonymous.cs at gmail dot com]

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

--- Comment #5 from Anonymous <iamanonymous.cs at gmail dot com> ---
(In reply to Tom Tromey from comment #3)
> You should probably attach your executable, since this is
> most likely compiler dependent.
> 
> One suggestion is to examine the line table and see what it says.
> Often this kind of behavior ends up being gdb doing what the
> compiler said to do.

Thanks for your reply. I have attached the executable the can reproduce this
potential issue.

It seems that Line 15, 25, 26 are both mapped to the same address of
0x00000000004011d0.

Does this indicate that this is a gcc issue?

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