[Bug debug/53770] New: Regression: incorrect line numbers in debug info since 4.5+

[Bug debug/53770] New: Regression: incorrect line numbers in debug info since 4.5+

[petschy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770

             Bug #: 53770
           Summary: Regression: incorrect line numbers in debug info since
                    4.5+
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: petschy@gmail.com


Created attachment 27703
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27703
the test case

Single stepping the code from the debugger shows bad lines at places, the code
is correct however.

Command to produce the executable:
g++-4.8.0 -o dbginfobug dbginfobug.cpp -save-temps -g -O0 -Wall -Wextra -v
Using built-in specs.
COLLECT_GCC=g++-4.8.0
COLLECT_LTO_WRAPPER=/home/usr-local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --program-suffix=-4.8.0
Thread model: posix
gcc version 4.8.0 20120605 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'dbginfobug' '-save-temps' '-g' '-O0' '-Wall'
'-Wextra' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/usr-local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus -E
-quiet -v -iprefix
/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/ -D_GNU_SOURCE
dbginfobug.cpp -mtune=generic -march=x86-64 -Wall -Wextra -g
-fworking-directory -O0 -fpch-preprocess -o dbginfobug.ii
ignoring nonexistent directory
"/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/usr-local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0"
ignoring duplicate directory
"/home/usr-local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu"
ignoring duplicate directory
"/home/usr-local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward"
ignoring duplicate directory
"/home/usr-local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include"
ignoring duplicate directory
"/home/usr-local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed"
ignoring nonexistent directory
"/home/usr-local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0

/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu

/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward
 /home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
 /home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-o' 'dbginfobug' '-save-temps' '-g' '-O0' '-Wall'
'-Wextra' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/usr-local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus
-fpreprocessed dbginfobug.ii -quiet -dumpbase dbginfobug.cpp -mtune=generic
-march=x86-64 -auxbase dbginfobug -g -O0 -Wall -Wextra -version -o dbginfobug.s
GNU C++ (GCC) version 4.8.0 20120605 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.8.0 20120605 (experimental), GMP version 5.0.5,
MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.8.0 20120605 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.8.0 20120605 (experimental), GMP version 5.0.5,
MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c6a0954413719d6fcdda7217d65221de
COLLECT_GCC_OPTIONS='-o' 'dbginfobug' '-save-temps' '-g' '-O0' '-Wall'
'-Wextra' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o dbginfobug.o dbginfobug.s
GNU assembler version 2.22 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.22
COMPILER_PATH=/home/usr-local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/:/home/usr-local/bin/../libexec/gcc/
LIBRARY_PATH=/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/:/home/usr-local/bin/../lib/gcc/:/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'dbginfobug' '-save-temps' '-g' '-O0' '-Wall'
'-Wextra' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/usr-local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
dbginfobug /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbegin.o
-L/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0
-L/home/usr-local/bin/../lib/gcc
-L/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../..
dbginfobug.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/usr-local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/crtend.o
/usr/lib/x86_64-linux-gnu/crtn.o

gcc used above was built from git commit e7ae865c. The machine was a Debian
Wheezy/AMD64 box. 4.8 produced the most weird behavior, although each minor
version starting from 4.5 had problems. 4.4 was ok, clang was also ok. gdb
version was 7.4.1.

This was the trace when stepping through the template function do_print(),
called from foo() with 'n' in gdb:

11              while (C c = *f++) {
12                      if (c == '$') {
56                              if (o < e) {
57                                      *o = c;
59                              ++o;
// the first anomaly: the line printed is AFTER the loop, while we're still in
the loop
// this happens only with 4.8, after each iteration
62              printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
11              while (C c = *f++) {
12                      if (c == '$') {
56                              if (o < e) {
57                                      *o = c;
59                              ++o;
62              printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
...
62              printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
11              while (C c = *f++) {
12                      if (c == '$') {
13                              C c2 = *f;
14                              if (c2 == '$') {
18                              unsigned ai = gai;
19                              if (c2 == '{') {
20                                      ++f;
21                                      C c3 = *f;
22                                      if (c3 >= '0' &&  c3 <= '9') {
23                                              ai = 0;
24                                              while (C c4 = *f) {
25                                                      if (c4 < '0'  ||  c4 >
'9') {
28                                                      ai *= 10;
29                                                      ai += c4 - '0';
30                                                      ++f;
24                                              while (C c4 = *f) {
25                                                      if (c4 < '0'  ||  c4 >
'9') {
// doesn't stop on the break with 4.8, stops with earlier versions

// !!! we should be after the closing brace of the loop, yet we're still inside
30                                                      ++f;
(gdb) p c4
// this is quite a gotcha: c4 of type C is not in the scope anymore, but some
constant
// of type mynumber creeps in the scope from libm.
// this wasn't too helpful understanding what's going on...
$16 = {i = {1431655765, -1079683755}, x = -0.041666666666666664}
(gdb) p f
$17 = 0x400a18 "}\n"
36                                              C x = *f++;
// f was not incremented (correctly), despite it stood on the line ++f
(gdb) p f
$18 = 0x400a18 "}\n"
37                                              if (x == '}') {
// now it stops on this break. what's the difference compared to the above if()
where it didn't stop?
38                                                      break;
62              printf("RESULT (%zu chars): '%s'\n", o - buf, buf);
11              while (C c = *f++) {
12                      if (c == '$') {

I also did another function, do_print2(), which is the same as do_print(), but
it's not a template, C is replaced with char. The interesting thing is, that
the trace is not exactly the same: if the condition is true in line 25/85, the
break is not stepped on. So far this is common. The templated version shows
line 30 (++f) after that, which is definitely incorrect, while the non-template
version shows line 91, which is the closing brace of the while loop, from which
we're breaking out.

[Bug debug/53770] Regression: incorrect line numbers in debug info since 4.5+

[petschy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53770

--- Comment #1 from petschy at gmail dot com 2012-06-25 20:29:05 UTC ---
I tested on 32bit Debian Wheezy, too, with stock 4.6.3, and everything was ok.

Another AMD64 Wheezy box w/ stock 4.6.3 showed the bug, with a minor variation:
when the condition in line 25 was true, it stepped on the break at line 26, but
then also stepped on line 30 with the ++f. The same is for 4.7.0.

Looking at the disassembly when standing on ++f:
   0x0000000000400a99 <+234>:    nop
=> 0x0000000000400a9a <+235>:    jmp    0x400aa0 <do_print<char>(char*,
unsigned long, char const*)+241>
   0x0000000000400a9c <+237>:    addl   $0x1,-0x14(%rbp)

The last insn is ++f, and the jump should belong to the break I guess.

[Bug debug/53770] Regression: incorrect line numbers in debug info since 4.5+

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-02-09
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Is this still true with GCC 4.9 or the trunk?

[Bug debug/53770] Regression: incorrect line numbers in debug info since 4.5+

[petschy at gmail dot com]

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

--- Comment #3 from petschy at gmail dot com ---
Tried now w/ g++ 4.9.1 (Debian 4.9.1-19), and single stepping is still wrong.
The only difference is that it doesn't stop on ++f in line 30 after breaking
out  from the loop. However, all the other bugs are still there.

Also tested w/ g++-5.0 (8fe6ab3):
- in do_print(), the outer loop iteration is OK, it doesn't stop now on the
last printf line
- it still doesn't step on the break; on line 26
- but then continues correctly on line 36 after breaking out (was: line 30 ++f)
- the difference is still present between the templated and non-templated
versions: do_print2(), the non-templated version jumps from line 85 to 91 (the
break is still skipped), which is the closing brace of the loop. The templated
version jumps to the first statement after the loop, correctly.

$ g++-5.0.0 -v
Using built-in specs.
COLLECT_GCC=g++-5.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-5.0.0
Thread model: posix
gcc version 5.0.0 20150203 (experimental) (GCC)

[Bug debug/53770] Regression: incorrect line numbers in debug info since 4.5+

[petschy at gmail dot com]

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

--- Comment #4 from petschy at gmail dot com ---
Clarification: I double checked now, and the templated and the non-templated
versions (do_print vs do_print2) are the same, with the same disassembly, only
the addresses differing. This is true for 4.9.1 and for 5.0, too. So my
previous statement that these two versions of the functions behave differently
doesn't hold. So I sum up again:

4.9.1:
- the printf (line 62 & 122) is stepped on in each loop iteration, this is the
jmp insn in the disassembly, that jumps to the beginning of the loop. the insns
for the printf start on the next insn.
- if the condition is true in line 25/85, the break; in line 26 is skipped and
it stops on line 36/96, which is the next statement after the break;
- upon loop exit, after stepping over the final printf (line 62/122), it jumps
back to the while() in line 11/71, and only prints if this while() is stepped
over, then goes to the closing brace in line 63/123

5.0:
- the printf (62/122) is not stepped on in each iteration, OK
- break; is not stepped on in line 25/85, as above, however, if the condition
is true, it jumps to line 31/91, the closing brace of the loop, and then to
line 36/96, the next statement. I think it should go immediately to the next
statement. The exception would be to run dtors upon loop exit, but this is not
the case now, as the variables are plain chars.
- the loop exit is OK, it doesn't jump back to the while() after the printf,
and prints when the printf is stepped over.

If I put a breakpoint to line 26/86 in the debugger (the break; that is
skipped), gdb says that placed the breakpoints on the same lines. However, when
single-stepping, it will break on line 28/88, if the condition is false. This
is the statement after the if() w/ the break; If the condition is true, it
won't stop on the breakpoint. This is true for both gcc versions tested.