[Bug debug/49951] New: Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0

["peter.thompson at roguewave dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

           Summary: Debug stepping behavior regarding g++ Class destructor
                    has changed for the worse starting at gcc 4.5.0
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: peter.thompson@roguewave.com


Created attachment 24896
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24896
Test source file

While this was reported to us as a problem with the TotalView debugger, the
same behavior is seen with gdb as well.   In short the call to a class
destructor no longer seems to take place inline or at the end (fini section) of
a routine, but instead jumps back to the declaration of the class instance,
before proceeding forward again.  So as one steps through the code, the
debugger focus appears to jump around the routine rather than proceeding in a
straight forward manner.  

Here is the test code from a user at the European Centre for Mid-Range Weather
Forecasting (ECMWF).

---------------------------------
#include <stdio.h>

class MyClass
{
public:
      MyClass() {};  // constructor
     ~MyClass() {};  // destructor
};


int main (int argc, char *argv[])
{
     int i = 1;
     MyClass m;

     if (i == 1)
     {
         printf ("Hello world %d\n", i);
     }
}
----------------------------------------------

Compile 

g++ -g -O0 -o myclass myclass.cxx

Debug

[petert@magny e30025_gcc-517] gdb myclass
GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6)
Copyright (C) 2010 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.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/nfs/netapp0/user/home/petert/repro/e30025_gcc/myclass...done.
(gdb) l
4       {
5       public:
6             MyClass() {};  // constructor
7            ~MyClass() {};  // destructor
8       };
9
10
11      int main (int argc, char *argv[])
12      {
13           int i = 1;
(gdb) b 13
Breakpoint 1 at 0x400614: file myclass.cxx, line 13.
(gdb) run
Starting program: /nfs/netapp0/user/home/petert/repro/e30025_gcc/myclass 

Breakpoint 1, main (argc=1, argv=0x7fffffffdb78) at myclass.cxx:13
13           int i = 1;
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6.x86_64
(gdb) n
14           MyClass m;
(gdb) n
16           if (i == 1)
(gdb) n
18               printf ("Hello world %d\n", i);
(gdb) n
Hello world 1
14           MyClass m;
(gdb) n
20      }
------------------------------------------------

The question here is why does a 'next' take us from line 18 to line 14, and
then back to 20?   Actually the 'why' is easy enough to see in the debug info
line number statements:

Line Number Statements:
  Extended opcode 2: set Address to 0x400674
  Special opcode 10: advance Address by 0 to 0x400674 and Line by 5 to 6
  Special opcode 117: advance Address by 8 to 0x40067c and Line by 0 to 6
  Advance PC by 2 to 0x40067e
  Extended opcode 1: End of Sequence

  Extended opcode 2: set Address to 0x40067e
  Special opcode 11: advance Address by 0 to 0x40067e and Line by 6 to 7
  Special opcode 117: advance Address by 8 to 0x400686 and Line by 0 to 7
  Advance PC by 2 to 0x400688
  Extended opcode 1: End of Sequence

  Extended opcode 2: set Address to 0x400604
  Advance Line by 11 to 12
  Copy
  Special opcode 230: advance Address by 16 to 0x400614 and Line by 1 to 13
  Special opcode 104: advance Address by 7 to 0x40061b and Line by 1 to 14
  Special opcode 175: advance Address by 12 to 0x400627 and Line by 2 to 16
  Special opcode 91: advance Address by 6 to 0x40062d and Line by 2 to 18
  Advance PC by constant 17 to 0x40063e
  Special opcode 43: advance Address by 3 to 0x400641 and Line by -4 to 14
  Advance PC by constant 17 to 0x400652
  Special opcode 11: advance Address by 0 to 0x400652 and Line by 6 to 20
  Advance Line by -6 to 14
  Special opcode 145: advance Address by 10 to 0x40065c and Line by 0 to 14
  Advance PC by 23 to 0x400673
  Extended opcode 1: End of Sequence
------------------------------------------------------------

This behavior was introduced in 4.5.0.  I have not tested all versions, but
4.4.1 stepped from line 18 to line 19 (the closing bracket) and never backed up
to line 14.  This is the expected behavior.  I've tested up to gcc 4.6.1 and
the new, annoying, behavior is still in place.

The specific version I used was:

 g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/nfs/netapp0/user/home/compilers/gnu/gcc/4.5.1/x86_64-linux/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../src/gcc-4.5.1/configure
--prefix=/home/compilers/gnu/gcc/4.5.1/x86_64-linux
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.1 (GCC)