Re: GDB 7.12.1: Strange "stepping" behavior

On 23/04/17 18:21, Simon Marchi wrote:
> On 2017-04-22 19:06, Richard Szibele wrote:
>> Hello everyone,
>>
>> I am experiencing strange stepping behavior with GDB 7.12.1 and a
>> program compiled with g++ (GCC) 5.4.0 which I can demonstrate with a
>> simple example:
>>
>>
>> #include <memory>
>> #include <iostream>
>>
>> int main()
>> {
>>     auto ptr = std::shared_ptr<int>(new int);
>>     *ptr = 100;
>>     std::cout << *ptr << std::endl;
>>     return 0;
>> }
>>
>>
>> I've compiled the above with the following g++ flags:
>>
>> g++ -std=c++14 -g -O0 main.cpp
>>
>> and then run gdb on the resulting executable.
>>
>> When I step over using "next" I end up jumping back and forth, rather
>> than a simple linear top-down progression in the source code. I've
>> read that this is due to compiler optimizations, but as I've supplied
>> the flags -g and -O0, I do not believe this should happen.
>>
>> Is this a bug or am I doing something wrong?
>>
>> Best Regards,
>> Richard Szibele
>
> Hi Richard,
>
> You probably see this sequence:
>
> Temporary breakpoint 1, main () at test.cpp:6
> 6        auto ptr = std::shared_ptr<int>(new int);
> (gdb) n
> 7        *ptr = 100;
> (gdb) n
> 8        std::cout << *ptr << std::endl;
> (gdb) n
> 100
> 9        return 0;
> (gdb) n
> 6        auto ptr = std::shared_ptr<int>(new int);
> (gdb) n
> 10    }
>
> It's jumping back to the declaration of "ptr" just before exiting the 
> scope of the main function.  This can be surprising at first, but is 
> perfectly normal given the implementation of next/step. The way step 
> works is equivalent to this.  The instruction you are stopped at 
> currently belongs (was generated from) a particular source line.  The 
> step command executes instructions until it reaches an instruction 
> that belongs to a different source line. next is the same except it 
> doesn't go into function calls.
>
> The simple fact that there's a variable of type std::shared_ptr<int> 
> declared in your scope means that the compiler must generate some code 
> to call the destructor of that variable.  This code is after the 
> "return 0", and was generated from the declaration of ptr.  That's why 
> after "return 0" it jumps to "auto ptr = ...".
>
> You can look at the instructions generated by the compiler using 
> "objdump -S a.out".  For reference, here's what I get: 
> https://pastebin.com/raw/rYPzbbeQ
>
> If you were to debug optimized code (you should give it a try), you'd 
> see that it jumps in a much more erratic and unexplainable way.
>
> Simon

Hi Simon,

I'll need to look more into this, but this seems to be a wrapper 
packaging issue on my system, as g++ outputs an identical binary 
according to objdump with -g -O0 and -g -Ofast on my system.

-g -O0: https://pastebin.com/raw/4kW5LHq5
-g -Ofast: https://pastebin.com/raw/q7s0NjcW

Just for reference, this is the sequence I get:

Temporary breakpoint 1, main () at main.cpp:5
5       {
(gdb) n
6           auto ptr = std::shared_ptr<int>(new int);
(gdb) n
5       {
(gdb) n
6           auto ptr = std::shared_ptr<int>(new int);
(gdb) n
8           std::cout << *ptr << std::endl;
(gdb) n
6           auto ptr = std::shared_ptr<int>(new int);
(gdb) n
7           *ptr = 100;
(gdb) n
6           auto ptr = std::shared_ptr<int>(new int);
(gdb) n
8           std::cout << *ptr << std::endl;
(gdb) n
100
6           auto ptr = std::shared_ptr<int>(new int);
(gdb) n
10      }

Many thanks for your input.

Best Regards,
Richard Szibele