3

When I have stack-allocated objects in a scope (a set of commands within curly brackets), and I use next at the end of that scope, gdb jumps back to where each of the stack-allocated objects are, in reverse order.

This is disturbing during a debug ritual: When there are a lot of stack-allocated instances of objects, the debugger jumps backward to each one, and only when it is finished does it proceed forward. Instead, I expect it to proceed to the next line after the scope.

Is there a way to configure gdb to not do that, or is this some flag that I need to pass to gcc when I'm building?

At first, I thought it was that I was compiling using -O0 or something (GDB jumps to wrong lines in out of order fashion), but that is not the case here.

Here is how I am building:

/opt/rh/devtoolset-6/root/usr/bin/c++  -MD -DDEBUG -g -ggdb -gstabs+  -fPIC  -Wall -Werror -Wsynth -Wno-comment -Wreturn-type   main.cpp -c -o main.o
/opt/rh/devtoolset-6/root/usr/bin/c++  -MD -DDEBUG -g -ggdb -gstabs+  -fPIC  -Wall -Werror -Wsynth -Wno-comment -Wreturn-type   main.o -L. -L/opt/rh/devtoolset-6/root/usr/lib64 -lstdc++  -o main.exe   

Below is what I'm seeing in the debugger. Notice the version of GDB involved:

bash-4.2$ gdb main.exe
GNU gdb (GDB) Red Hat Enterprise Linux 7.12.1-48.el6
Copyright (C) 2017 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main.exe...done.
(gdb) b main
Breakpoint 1 at 0x400a27: file main.cpp, line 45.
(gdb) r
Starting program: /home/brentg/scratch_sandboxes/cxxminimal/main.exe 
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.x86_64

Breakpoint 1, main (argc=1, argv=0x7fffffffeb38, envp=0x7fffffffeb48)
    at main.cpp:45
45    std::cout << __FILE__ << ":" << __LINE__ << ":" << "main begin" << std::endl;
Missing separate debuginfos, use: debuginfo-install libgcc-4.4.7-17.el6.x86_64 libstdc++-4.4.7-17.el6.x86_64
(gdb) l
40    std::cout << __FILE__ << ":" << __LINE__ << ":" << "printing some info 2" << std::endl;
41  }
42  
43  int main(int argc, char *argv[], char *const envp[])
44  {
45    std::cout << __FILE__ << ":" << __LINE__ << ":" << "main begin" << std::endl;
46    some_function_that_uses_Foo();
47    std::cout << __FILE__ << ":" << __LINE__ << ":" << "main end" << std::endl;
48    return 0;
49  } // end main
(gdb) n
main.cpp:45:main begin
46    some_function_that_uses_Foo();
(gdb) s
some_function_that_uses_Foo () at main.cpp:38
38    std::cout << __FILE__ << ":" << __LINE__ << ":" << "printing some info 1" << std::endl;
(gdb) n
main.cpp:38:printing some info 1
39    Foo the_foo1;
(gdb) n
40    std::cout << __FILE__ << ":" << __LINE__ << ":" << "printing some info 2" << std::endl;
(gdb) l
35  
36  void some_function_that_uses_Foo()
37  {
38    std::cout << __FILE__ << ":" << __LINE__ << ":" << "printing some info 1" << std::endl;
39    Foo the_foo1;
40    std::cout << __FILE__ << ":" << __LINE__ << ":" << "printing some info 2" << std::endl;
41  }
42  
43  int main(int argc, char *argv[], char *const envp[])
44  {
(gdb) n
main.cpp:40:printing some info 2
39    Foo the_foo1;

At this point, I wonder: Why am I now back on line 39? When I was on line 40, entering in "next", then it seemingly jumps backwards.

Looking at the gdb manual for the "next" command, I do not see anything in regards to C++ constructors/destructors.

bgoodr
  • 2,744
  • 1
  • 30
  • 51
  • 1
    i meet the "issue" you stated everyday, because gdb will jump to the destructor of you local objects. I think it is by design, there are many discussion about this in gdb maillist. – ollydbg23 Sep 21 '18 at 01:13
  • @ollydbg23 Thank you. I searched and found https://sourceware.org/ml/gdb/2011-10/msg00214.html that implies that it is GCC's responsibility to emit debug information that GDB can use to determine where to stop. This really isn't an answer for me quite yet, but it might help in producing an answer. – bgoodr Oct 01 '18 at 14:14
  • https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951#c21 is the last comment on that bug at 2015-02-03 01:04:40 UTC. It is still not fixed and it is now deep into 2018. – bgoodr Oct 01 '18 at 15:20
  • Aha, that commenter named "asmwarrior" is me. I really forget it is a GDB bug or GCC bug, hope we can "ping" on this bug report, and some devs can step forward to fix this issue. – ollydbg23 Oct 02 '18 at 14:32

1 Answers1

0

/opt/rh/devtoolset-6/root/usr/bin/c++ -MD -DDEBUG -g -ggdb -gstabs+ ...

You may be suffering from self-inflicted wounds.

The STABS debugging format is ancient, and should not be used on any system less than 15 years old. It is also totally inadequate and completely untested.

libgcc-4.4.7-17.el6.x86_64

You are also using ancient GCC-4.4.7, which was released in March of 2012. You will likely get better debugging experience using a more modern version.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • 1
    First, this is good advice, do not use stabs. Second, this stepping behavior will happen with DWARF as well, because gcc tells gdb to step into the destructors. I don't think there's a flag to disable this. Maybe you can use the `skip` command. – Tom Tromey Sep 18 '18 at 11:18
  • Upon further research, I conclude that this is a bug that has yet to be fixed. See comment at https://stackoverflow.com/questions/52360140/gdbs-next-command-jumps-backward-to-all-stack-allocated-objects-at-end-of-scope?noredirect=1#comment92123188_52360140 – bgoodr Oct 01 '18 at 15:21
  • I went back and examined the actual version of GCC that I'm using and it shows "c++ (GCC) 6.2.1 20160916 (Red Hat 6.2.1-3)", not the "ancient GCC-4.4.7" version as indicated in this answer. – bgoodr Oct 01 '18 at 15:22
  • Also, I tried using a build using the above GCC 6.2.1 compiler, but using `-gsplit-dwarf` option (https://gcc.gnu.org/wiki/DebugFission), and it exhibits the same problem. – bgoodr Oct 01 '18 at 15:25