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: unassig...@gcc.gnu.org ReportedBy: peter.thomp...@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)