[Bug debug/95360] New: inconsistent behaviors at -O0

[Bug debug/95360] New: inconsistent behaviors at -O0

[yangyibiao at hust dot edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

            Bug ID: 95360
           Summary: inconsistent behaviors at -O0
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yangyibiao at hust dot edu.cn
  Target Milestone: ---

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


$ cat small.c
unsigned int b,d;
static int c[1][2] = {{0, 1}};

int main() {
  for (; d<1; d++)
    for (; b<1; b++)
      c[b][d+1] = 0;

  return 0;
}


$ gcc -O0 -g small.c

$ gdb -q a.out
Reading symbols from a.out...
(gdb) b 5
Breakpoint 1 at 0x401106: file small.c, line 5.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:5
5         for (; d<1; d++)
(gdb) stepi
0x0000000000401154      5         for (; d<1; d++)
(gdb) stepi
0x000000000040115a      5         for (; d<1; d++)
(gdb) stepi
0x000000000040115c      5         for (; d<1; d++)
(gdb) stepi
0x000000000040113b      6           for (; b<1; b++)
(gdb) stepi
0x0000000000401141      6           for (; b<1; b++)
(gdb) stepi
0x0000000000401143      6           for (; b<1; b++)
(gdb) stepi
7             c[b][d+1] = 0;
(gdb)


/*****************************************************
As showed, Line 6 is hit first and then hit Line 7 with stepi.
However, when using step, gdb is first hit Line 7 and then hit Line 6.
This is an inconsistent behaviors between stepi and step
*****************************************************/


$ gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401106: file small.c, line 5.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:5
5         for (; d<1; d++)
(gdb) step
7             c[b][d+1] = 0;
(gdb) 
6           for (; b<1; b++)
(gdb) 


Breakpoint 1, main () at small.c:6
6           for (; b<1; b++)
(gdb)

[Bug debug/95360] inconsistent behaviors at -O0

[yangyibiao at hust dot edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

--- Comment #1 from Yibiao Yang <yangyibiao at hust dot edu.cn> ---
Created attachment 48616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48616&action=edit
the binary

[Bug debug/95360] inconsistent behaviors at -O0

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Yibiao Yang from comment #0)
> As showed, Line 6 is hit first and then hit Line 7 with stepi.
> However, when using step, gdb is first hit Line 7 and then hit Line 6.
> This is an inconsistent behaviors between stepi and step

Why is that a bug? Why is it a GCC bug?

[Bug debug/95360] inconsistent behaviors at -O0

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

[Bug debug/95360] inconsistent behaviors at -O0

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Yibiao Yang from comment #0)
> Breakpoint 1, main () at small.c:5
> 5	  for (; d<1; d++)
> (gdb) stepi
> 0x0000000000401154	5	  for (; d<1; d++)
> (gdb) stepi
> 0x000000000040115a	5	  for (; d<1; d++)
> (gdb) stepi
> 0x000000000040115c	5	  for (; d<1; d++)
> (gdb) stepi
> 0x000000000040113b	6	    for (; b<1; b++)
> (gdb) stepi
> 0x0000000000401141	6	    for (; b<1; b++)
> (gdb) stepi
> 0x0000000000401143	6	    for (; b<1; b++)
> (gdb) stepi
> 7	      c[b][d+1] = 0;
> (gdb)
> 
> 
> /*****************************************************
> As showed, Line 6 is hit first and then hit Line 7 with stepi.
> However, when using step, gdb is first hit Line 7 and then hit Line 6.
> This is an inconsistent behaviors between stepi and step
> *****************************************************/

Gdb is behaving consistently in the following sense:
- when gdb is at a "recommended breakpoint location" it shows the source line
  only with line number prefix.
- otherwise, it shows the source line with both address and line number prefix.

So, what the stepi sequence shows it that the next "recommended breakpoint
location" after line 5 is line 7, which is consistent with a step from line 5
to line 7.

[Bug debug/95360] inconsistent behaviors at -O0

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
I compiled the test-case:
...
$ gcc-10 -O0 -g small.c
...

And did the stepi scenario:
...
$ gdb a.out -batch -ex start $(for n in $(seq 1 7); do echo -ex si; done)
Temporary breakpoint 1 at 0x400496: file small.c, line 5.

Temporary breakpoint 1, main () at small.c:5
5         for (; d<1; d++)
0x00000000004004e4      5         for (; d<1; d++)
0x00000000004004ea      5         for (; d<1; d++)
0x00000000004004ec      5         for (; d<1; d++)
0x00000000004004cb      6           for (; b<1; b++)
0x00000000004004d1      6           for (; b<1; b++)
0x00000000004004d3      6           for (; b<1; b++)
7             c[b][d+1] = 0;
...

The line table gdb uses is:
...
$ gdb a.out -batch -ex start -ex "maint info line-table"
Temporary breakpoint 1 at 0x400496: file small.c, line 5.

Temporary breakpoint 1, main () at small.c:5
5         for (; d<1; d++)
objfile: a.out ((struct objfile *) 0x2f2f520)
compunit_symtab: ((struct compunit_symtab *) 0x2f618e0)
symtab: small.c ((struct symtab *) 0x2f61960)
linetable: ((struct linetable *) 0x2fa3ae0):
INDEX  LINE   ADDRESS            IS-STMT 
0      4      0x0000000000400492 Y 
1      5      0x0000000000400496 Y 
2      7      0x0000000000400498 Y 
3      6      0x00000000004004bc Y 
4      5      0x00000000004004d5 Y 
5      9      0x00000000004004ee Y 
6      10     0x00000000004004f3 Y 
7      END    0x00000000004004f5 Y 
...

And indeed, the insn at 0x00000000004004cb is not a "recommended breakpoint
location" in this table.

However, if we look in the line number program using readelf -wl we see an
entry with that address:
...
  [0x00000145]  Special opcode 215: advance Address by 15 to 0x4004cb and Line
by 0 to 6
...

The whole line number program looks like this:
...
 Line Number Statements:
  [0x00000111]  Set column to 12
  [0x00000113]  Extended opcode 2: set Address to 0x400492
  [0x0000011e]  Special opcode 8: advance Address by 0 to 0x400492 and Line by
3 to 4
  [0x0000011f]  Set column to 3
  [0x00000121]  Special opcode 62: advance Address by 4 to 0x400496 and Line by
1 to 5
  [0x00000122]  Set column to 11
  [0x00000124]  Extended opcode 4: set Discriminator to 2
  [0x00000128]  Special opcode 35: advance Address by 2 to 0x400498 and Line by
2 to 7
  [0x00000129]  Set column to 13
  [0x0000012b]  Extended opcode 4: set Discriminator to 2
  [0x0000012f]  Special opcode 89: advance Address by 6 to 0x40049e and Line by
0 to 7
  [0x00000130]  Set column to 17
  [0x00000132]  Extended opcode 4: set Discriminator to 2
  [0x00000136]  Special opcode 131: advance Address by 9 to 0x4004a7 and Line
by 0 to 7
  [0x00000137]  Set column to 18
  [0x00000139]  Extended opcode 4: set Discriminator to 2
  [0x0000013d]  Advance PC by constant 17 to 0x4004b8
  [0x0000013e]  Special opcode 60: advance Address by 4 to 0x4004bc and Line by
-1 to 6
  [0x0000013f]  Set column to 13
  [0x00000141]  Extended opcode 4: set Discriminator to 1
  [0x00000145]  Special opcode 215: advance Address by 15 to 0x4004cb and Line
by 0 to 6
  [0x00000146]  Set column to 5
  [0x00000148]  Extended opcode 4: set Discriminator to 1
  [0x0000014c]  Special opcode 89: advance Address by 6 to 0x4004d1 and Line by
0 to 6
  [0x0000014d]  Set column to 16
  [0x0000014f]  Special opcode 60: advance Address by 4 to 0x4004d5 and Line by
-1 to 5
  [0x00000150]  Set column to 11
  [0x00000152]  Extended opcode 4: set Discriminator to 1
  [0x00000156]  Special opcode 215: advance Address by 15 to 0x4004e4 and Line
by 0 to 5
  [0x00000157]  Set column to 3
  [0x00000159]  Extended opcode 4: set Discriminator to 1
  [0x0000015d]  Special opcode 89: advance Address by 6 to 0x4004ea and Line by
0 to 5
  [0x0000015e]  Set column to 10
  [0x00000160]  Special opcode 65: advance Address by 4 to 0x4004ee and Line by
4 to 9
  [0x00000161]  Set column to 1
  [0x00000163]  Special opcode 76: advance Address by 5 to 0x4004f3 and Line by
1 to 10
  [0x00000164]  Advance PC by 2 to 0x4004f5
  [0x00000166]  Extended opcode 1: End of Sequence
...

So, it seems gdb ignores the "recommended breakpoint location" at 0x4004cb,
because there's an earlier one on the same line at 0x4004bc.

The gdb approach is reasonable, but it could do better.

It will be interesting to see how this example is handled by this (
https://sourceware.org/pipermail/gdb-patches/2020-May/168673.html ) gdb patch
series.

[Bug debug/95360] inconsistent behaviors at -O0

[yangyibiao at hust dot edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

--- Comment #5 from Yibiao Yang <yangyibiao at hust dot edu.cn> ---
(In reply to Tom de Vries from comment #3)
> (In reply to Yibiao Yang from comment #0)
> > Breakpoint 1, main () at small.c:5
> > 5	  for (; d<1; d++)
> > (gdb) stepi
> > 0x0000000000401154	5	  for (; d<1; d++)
> > (gdb) stepi
> > 0x000000000040115a	5	  for (; d<1; d++)
> > (gdb) stepi
> > 0x000000000040115c	5	  for (; d<1; d++)
> > (gdb) stepi
> > 0x000000000040113b	6	    for (; b<1; b++)
> > (gdb) stepi
> > 0x0000000000401141	6	    for (; b<1; b++)
> > (gdb) stepi
> > 0x0000000000401143	6	    for (; b<1; b++)
> > (gdb) stepi
> > 7	      c[b][d+1] = 0;
> > (gdb)
> > 
> > 
> > /*****************************************************
> > As showed, Line 6 is hit first and then hit Line 7 with stepi.
> > However, when using step, gdb is first hit Line 7 and then hit Line 6.
> > This is an inconsistent behaviors between stepi and step
> > *****************************************************/
> 
> Gdb is behaving consistently in the following sense:
> - when gdb is at a "recommended breakpoint location" it shows the source line
>   only with line number prefix.
> - otherwise, it shows the source line with both address and line number
> prefix.
> 
> So, what the stepi sequence shows it that the next "recommended breakpoint
> location" after line 5 is line 7, which is consistent with a step from line
> 5 to line 7.

I agree that at some time it will step to line 7 after executing line 6  and at
other times it will step to line 6 after executing line7  as they both at the
same iteration. 

However, my concern is that for the "first iteration or first time" line 6
should be hit ahead of line 7 no matter on whether we using step or using
stepi. That's to say, the first hit of Line 6 or Line 7 should be consistent
between step and stepi.

[Bug debug/95360] inconsistent behaviors at -O0

[yangyibiao at hust dot edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

--- Comment #6 from Yibiao Yang <yangyibiao at hust dot edu.cn> ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Yibiao Yang from comment #0)
> > As showed, Line 6 is hit first and then hit Line 7 with stepi.
> > However, when using step, gdb is first hit Line 7 and then hit Line 6.
> > This is an inconsistent behaviors between stepi and step
> 
> Why is that a bug? Why is it a GCC bug?

To be honest, I am not sure whether this is a gcc bug or a gdb bug. I am very
sorry for that. 
I report it here as I doubt that the line table is generated incorrectly by
compilers.

[Bug debug/95360] inconsistent behaviors at -O0

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #4)
> So, it seems gdb ignores the "recommended breakpoint location" at 0x4004cb,
> because there's an earlier one on the same line at 0x4004bc.
> 
> The gdb approach is reasonable, but it could do better.
> 

I found how to disable this behaviour in gdb, and then we do step from line 5
to line 6.

Filed gdb PR https://sourceware.org/bugzilla/show_bug.cgi?id=26054 .

[Bug debug/95360] inconsistent behaviors at -O0

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |MOVED

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is a gdb issue so closing as moved.