[Bug symtab/26063] New: inconsistent behaviors at -O2

[Bug symtab/26063] New: inconsistent behaviors at -O2

[yangyibiao at hust dot edu.cn]

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

            Bug ID: 26063
           Summary: inconsistent behaviors at -O2
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: yangyibiao at hust dot edu.cn
  Target Milestone: ---

Consider test case:
...
$ cat small.c
__attribute__ ((noinline, noclone)) 
int foo (char *c)
{
  asm volatile ("" : : "r" (c) : "memory");
  return 1;
}

int main ()
{
  char tpl1[20] = "/tmp/test.XXX";
  char tpl2[20] = "/tmp/test.XXX";
  int fd1 = foo (tpl1);
  int fd2 = foo (tpl2);
  if (fd1 == -1) {
    return 1;
  }

  return 0;
}
...



When stepping with step, line 13 is not hit by gdb.
...
$ gcc -O2 -g small.c; gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401020: file small.c, line 10.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:10
10        char tpl1[20] = "/tmp/test.XXX";
(gdb) step
11        char tpl2[20] = "/tmp/test.XXX";
(gdb) 
12        int fd1 = foo (tpl1);
(gdb) 
foo (c=c@entry=0x7fffffffdea0 "/tmp/test.XXX") at small.c:5
5         return 1;
(gdb) 
foo (c=c@entry=0x7fffffffdec0 "/tmp/test.XXX") at small.c:5
5         return 1;
(gdb) 
main () at small.c:14
14        if (fd1 == -1) {
(gdb) 
0x00007ffff7df4023 in __libc_start_main () from /usr/lib/libc.so.6
(gdb) 
Single stepping until exit from function __libc_start_main,
which has no line number information.
[Inferior 1 (process 1852557) exited normally]
...



When stepping with stepi, line 13 is hit by gdb as follow.
...
$ gcc -O2 -g small.c; gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401020: file small.c, line 10.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:10
10        char tpl1[20] = "/tmp/test.XXX";
(gdb) stepi
0x0000000000401024      10        char tpl1[20] = "/tmp/test.XXX";
(gdb) 
0x000000000040102c      12        int fd1 = foo (tpl1);
(gdb) 
0x000000000040102f      10        char tpl1[20] = "/tmp/test.XXX";
(gdb) 
11        char tpl2[20] = "/tmp/test.XXX";
(gdb) 
12        int fd1 = foo (tpl1);
(gdb) 
0x0000000000401043      11        char tpl2[20] = "/tmp/test.XXX";
(gdb) 
0x0000000000401048      12        int fd1 = foo (tpl1);
(gdb) 
foo (c=c@entry=0x7fffffffdea0 "/tmp/test.XXX") at small.c:5
5         return 1;
(gdb) 
0x0000000000401165      5         return 1;
(gdb) 
0x000000000040104d in main () at small.c:13
13        int fd2 = foo (tpl2);
(gdb) 
...


$ gcc --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gdb --version
GNU gdb (GDB) 10.0.50.20200517-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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

[Bug symtab/26063] inconsistent behaviors at -O2

[yangyibiao at hust dot edu.cn]

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

Yibiao Yang <yangyibiao at hust dot edu.cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

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

[Bug symtab/26063] inconsistent behaviors at -O2

[yangyibiao at outlook dot com]

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

Yibiao Yang <yangyibiao at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yangyibiao at outlook dot com

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

[Bug symtab/26063] inconsistent behaviors at -O2

[yangyibiao at outlook dot com]

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

Yibiao Yang <yangyibiao at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #1 from Yibiao Yang <yangyibiao at outlook dot com> ---
Note that, this issue can be reproduced in the latest version of gdb.


$ cat small.c
__attribute__ ((noinline, noclone)) 
int foo (char *c)
{
  asm volatile ("" : : "r" (c) : "memory");
  return 1;
}

int main ()
{
  char tpl1[20] = "/tmp/test.XXX";
  char tpl2[20] = "/tmp/test.XXX";
  int fd1 = foo (tpl1);
  int fd2 = foo (tpl2); // L13
  if (fd1 == -1) {
    return 1;
  }

  return 0;
}


Line 13 is "IS-STMT" which can be observed in the line-table. 

(gdb) maint info line-table
objfile: /home/yibiao/DeVIL/a.out ((struct objfile *) 0x55cf48fb2d50)
compunit_symtab: ((struct compunit_symtab *) 0x55cf48faa180)
symtab: /home/yibiao/DeVIL/small.c ((struct symtab *) 0x55cf48faa200)
linetable: ((struct linetable *) 0x55cf48ff3640):
INDEX  LINE   ADDRESS            IS-STMT 
0      9      0x0000555555555060 Y 
1      10     0x0000555555555068   
2      9      0x0000555555555070   
3      10     0x0000555555555080 Y 
4      12     0x0000555555555080   
5      10     0x0000555555555083   
6      11     0x000055555555508b Y 
7      11     0x000055555555508b   
8      12     0x0000555555555093 Y 
9      10     0x0000555555555093   
10     11     0x0000555555555097   
11     12     0x000055555555509c   
12     13     0x00005555555550a1   
13     12     0x00005555555550a6   
14     13     0x00005555555550a8 Y 
15     13     0x00005555555550a8   
16     14     0x00005555555550ad Y 
17     14     0x00005555555550ad   
18     19     0x00005555555550b3   
19     END    0x00005555555550d0 Y 
20     3      0x00005555555551c0 Y 
21     3      0x00005555555551c0   
22     4      0x00005555555551c4 Y 
23     5      0x00005555555551c4 Y 
24     6      0x00005555555551c4   
25     END    0x00005555555551ca Y


$ gcc --version; gdb --version
gcc (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GNU gdb (GDB) 11.0.50.20210113-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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

[Bug symtab/26063] inconsistent behaviors at -O2

[yangyibiao at outlook dot com]

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

--- Comment #2 from Yibiao Yang <yangyibiao at outlook dot com> ---
I tried it in lldb as well and lldb behaves as expected.

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

[Bug symtab/26063] inconsistent behaviors at -O2

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
This looks like fallout from the is-stmt tracking.

Using this experimentation patch:
...
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 45bedf89641..53b1d2a32d4 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -6995,7 +6995,7 @@ process_event_stop_test (struct execution_control_state
*ecs)
       return;
     }

-  bool refresh_step_info = true;
+  bool refresh_step_info = false;
   if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
       && (ecs->event_thread->current_line != stop_pc_sal.line
          || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
...
we get the desired stepping behaviour:
...
$ gdb -batch -q a.out -ex start -ex next -ex next -ex step -ex step
Temporary breakpoint 1 at 0x4003c0: file small.c, line 10.

Temporary breakpoint 1, main () at small.c:10
10        char tpl1[20] = "/tmp/test.XXX";
11        char tpl2[20] = "/tmp/test.XXX";
12        int fd1 = foo (tpl1);
foo (c=c@entry=0x7fffffffdbc0 "/tmp/test.XXX") at small.c:5
5         return 1;
main () at small.c:13
13        int fd2 = foo (tpl2);
...


The problem is triggered as follows.

We have these insns:
....
  4003df:       0f 29 04 24             movaps %xmm0,(%rsp)
  4003e3:       0f 29 44 24 20          movaps %xmm0,0x20(%rsp)
  4003e8:       e8 03 01 00 00          callq  4004f0 <foo>
  4003ed:       48 8d 7c 24 20          lea    0x20(%rsp),%rdi
  4003f2:       89 c2                   mov    %eax,%edx
  4003f4:       e8 f7 00 00 00          callq  4004f0 <foo>
  4003f9:       31 c0                   xor    %eax,%eax
...
with this corresponding line info:
...
linetable: ((struct linetable *) 0x40c1160):
INDEX  LINE   ADDRESS            IS-STMT 
8      12     0x00000000004003df Y 
9      10     0x00000000004003df   
10     11     0x00000000004003e3   
11     12     0x00000000004003e8   
12     13     0x00000000004003ed   
13     12     0x00000000004003f2   
14     13     0x00000000004003f4 Y 
15     13     0x00000000004003f4   
16     14     0x00000000004003f9 Y 
17     14     0x00000000004003f9   
...

Once we step out of the call to foo at 4003e8, we land at 4003ed.

That entry has IS-STMT=N, so it's not the start of a line, so we don't stop
there.

OTOH, due refresh_step_info=true, we update ecs->event_thread->current_line to
13.

Next we land at 4003f2.  Again the entry has IS-STMT=N, so it's not the start
of a line, so we don't stop there. However, we don't update
ecs->event_thread->current_line because refresh_step_info=false, due to hitting
the "stepped to a different line, but it's not the start of a statement" case.

Next we land at 4003f4.  We would really like to stop here. IS-STMT=Y, so it's
the start of a line.  But we can't because this test fails:
...
  if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
      && (ecs->event_thread->current_line != stop_pc_sal.line
          || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
    {
...
because stop_pc_sal.line == 13 and ecs->event_thread->current_line == 13.

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

[Bug symtab/26063] inconsistent behaviors at -O2

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, this could work, let's put it through some testing:
...
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 940f575e22a..49fbad35296 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -7021,6 +7021,16 @@ process_event_stop_test (struct execution_control_state
*ecs)
          infrun_debug_printf ("stepped to a different line, but "
                               "it's not the start of a statement");
        }
+      else
+       {
+         /* We are at the start of a different line, however, this line is
+            not marked as a statement, and we have changed frame.  We
+            ignore this line table entry, and continue stepping forward,
+            looking for a better place to stop.
+            Because we have changed frame, set stop_pc_sal.line to 0, to let
+            set_step_info set ecs->event_thread->current_line to 0.  */
+         stop_pc_sal.line = 0;
+       }
     }

   /* We aren't done stepping.
...

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

[Bug breakpoints/26063] inconsistent behaviors at -O2

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|symtab                      |breakpoints

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

[Bug breakpoints/26063] inconsistent behaviors at -O2

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2021-January/175104.html

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

[Bug breakpoints/26063] inconsistent behaviors at -O2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebde6f2ddc987e7e2d5a218ee8cf0126ec189424

commit ebde6f2ddc987e7e2d5a218ee8cf0126ec189424
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Jan 29 13:36:52 2021 +0100

    [gdb/breakpoint] Fix stepping past non-stmt line-table entries

    Consider the test-case small.c:
    ...
    $ cat -n small.c
         1  __attribute__ ((noinline, noclone))
         2  int foo (char *c)
         3  {
         4    asm volatile ("" : : "r" (c) : "memory");
         5    return 1;
         6  }
         7
         8  int main ()
         9  {
        10    char tpl1[20] = "/tmp/test.XXX";
        11    char tpl2[20] = "/tmp/test.XXX";
        12    int fd1 = foo (tpl1);
        13    int fd2 = foo (tpl2);
        14    if (fd1 == -1) {
        15      return 1;
        16    }
        17
        18    return 0;
        19  }
    ...

    Compiled with gcc-8 and optimization:
    ...
    $ gcc-8 -O2 -g small.c
    ...

    We step through the calls to foo, but fail to visit line 13:
    ...
    12        int fd1 = foo (tpl1);
    (gdb) step
    foo (c=c@entry=0x7fffffffdea0 "/tmp/test.XXX") at small.c:5
    5         return 1;
    (gdb) step
    foo (c=c@entry=0x7fffffffdec0 "/tmp/test.XXX") at small.c:5
    5         return 1;
    (gdb) step
    main () at small.c:14
    14        if (fd1 == -1) {
    (gdb)
    ...

    This is caused by the following.  The calls to foo are implemented by these
    insns:
    ....
      4003df:       0f 29 04 24             movaps %xmm0,(%rsp)
      4003e3:       0f 29 44 24 20          movaps %xmm0,0x20(%rsp)
      4003e8:       e8 03 01 00 00          callq  4004f0 <foo>
      4003ed:       48 8d 7c 24 20          lea    0x20(%rsp),%rdi
      4003f2:       89 c2                   mov    %eax,%edx
      4003f4:       e8 f7 00 00 00          callq  4004f0 <foo>
      4003f9:       31 c0                   xor    %eax,%eax
    ...
    with corresponding line table entries:
    ...
    INDEX  LINE   ADDRESS            IS-STMT
    8      12     0x00000000004003df Y
    9      10     0x00000000004003df
    10     11     0x00000000004003e3
    11     12     0x00000000004003e8
    12     13     0x00000000004003ed
    13     12     0x00000000004003f2
    14     13     0x00000000004003f4 Y
    15     13     0x00000000004003f4
    16     14     0x00000000004003f9 Y
    17     14     0x00000000004003f9
    ...

    Once we step out of the call to foo at 4003e8, we land at 4003ed, and gdb
    enters process_event_stop_test to figure out what to do.

    That entry has is-stmt=n, so it's not the start of a line, so we don't stop
    there.  However, we do update ecs->event_thread->current_line to line 13,
    because the frame has changed (because we stepped out of the function).

    Next we land at 4003f2.  Again the entry has is-stmt=n, so it's not the
start
    of a line, so we don't stop there.  However, because the frame hasn't
changed,
    we don't update update ecs->event_thread->current_line, so it stays 13.

    Next we land at 4003f4.  Now is-stmt=y, so it's the start of a line, and
we'd
    like to stop here.

    But we don't stop because this test fails:
    ...
      if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
          && (ecs->event_thread->current_line != stop_pc_sal.line
              || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
        {
    ...
    because ecs->event_thread->current_line == 13 and stop_pc_sal.line == 13.

    Fix this by resetting ecs->event_thread->current_line to 0 if is-stmt=n and
    the frame has changed, such that we have:
    ...
    12        int fd1 = foo (tpl1);
    (gdb) step
    foo (c=c@entry=0x7fffffffdbc0 "/tmp/test.XXX") at small.c:5
    5         return 1;
    (gdb) step
    main () at small.c:13
    13        int fd2 = foo (tpl2);
    (gdb)
    ...

    Tested on x86_64-linux, with gcc-7 and gcc-8.

    gdb/ChangeLog:

    2021-01-29  Tom de Vries  <tdevries@suse.de>

            PR breakpoints/26063
            * infrun.c (process_event_stop_test): Reset
            ecs->event_thread->current_line to 0 if is-stmt=n and frame has
            changed.

    gdb/testsuite/ChangeLog:

    2021-01-29  Tom de Vries  <tdevries@suse.de>

            PR breakpoints/26063
            * gdb.dwarf2/dw2-step-out-of-function-no-stmt.c: New test.
            * gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp: New file.

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

[Bug breakpoints/26063] inconsistent behaviors at -O2

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |11.1

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch with test-case committed, marking resolved-fixed.

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