Re: Does -Og work well?

[Xi Ruoyao <xry111@mengyan1223.wang>]

> Does -Og work well?

No, IMO.

When I need to debug some code I always use -O0 (unless it produces
really stupidly slow code).

On Mon, 2021-10-11 at 17:47 +0000, Nick Savoiu via Gcc-help wrote:
> Hi all, I've been trying for some time to use the recommended -Og for
> the edit/compile/debug/repeat cycle. The hope was to speed up the
> code.
> 
> The code does get a speed-up, however, more often than not, I'm
> running into issues that affect debugability: variables are marked as
> optimized when not expecting them to, breakpoints don't work, etc.
> 
> Is anyone having such issues? If so, how do you resolve them? I tried
> -fvar-tracking-assignments and that helps here and there but it's no
> panacea.
> 
> For the code below, here's what I see using Ubuntu 20.04 + GCC 9.3.0 +
> GDB 9.2:
> 
> nick@localhost:~$ g++ -g blah.cpp -o blah
> nick@localhost:~$ gdb -quiet blah
> Reading symbols from blah...
> (gdb) b blah.cpp:33
> Breakpoint 1 at 0x29e1: file blah.cpp, line 33.
> (gdb) info b
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep y   0x00000000000029e1 in main(int,
> char**) at blah.cpp:33
> (gdb) quit
> nick@localhost:~$ g++ -g -Og blah.cpp -o blah
> nick@localhost:~$ gdb -quiet blah
> Reading symbols from blah...
> (gdb) b blah.cpp:33
> Breakpoint 1 at 0x12e9: blah.cpp:33. (2 locations)
> (gdb) info b
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep y   <MULTIPLE>
> 1.1                         y   0x00000000000012e9 in
> __static_initialization_and_destruction_0(int, int)
>                                                    at blah.cpp:40
> 1.2                         y   0x0000000000001b47 in
> _GLOBAL__sub_I__Z6get_niB5cxx11ci() at blah.cpp:40
> (gdb) quitnick@localhost:~$
> 
> How did blah.cpp:33 get transformed into blah.cpp:40?

It's caused by inlining.  -fno-inline should help in this case (why -
finline is even in -Og?) but again I just prefer -O0 for debugging.

> Also, if I use -Og and step up to line 31 I can still see the value of
> fnih. However, the moment I move on to line 32, fnih is marked as
> "optimized out". I can sort of see that fnih is no longer needed after
> line 31 but that makes it hard to see how 'id' got its value. And this
> is a simple testcase. For more complicated code it's not always clear
> why something was marked as "optimized out"

The optimizer put fnih (which is a pointer: reference is simply a snack
of pointer) into an register.  In the following code the register
holding it is reused, with other values spilled into this register. 
Basically there is no way for the debugger to recover its value at all.

On -O0 local variables are forced into stack even if it's unnecessary,
so the debugger can recover the value from the stack.

> Nick
> 
> CODE:
> 
> #include <string>
> #include <iostream>
> 
> std::string get_ni(char const fnih, int const p)
> {
>     return std::string(1,fnih) + "_" + std::to_string(p);
> }
> 
> int main(int,char**)
> {
>     std::string res;
>     std::string array[10][10];
>     for (auto& a : array)
>         for (auto& b : a)
>             b="fsahjdsyuufdsiufdsufds";
>     auto dx = 0;
>     for (auto p = 0; p < 2; ++p)
>     {
>         auto cx = 0;
>         for (auto s = 0; s < 2; ++s)
>         {
>             for (auto d = 0; d < 4; ++d)
>             {
>                 if (d % 2 != s)
>                     continue;
> 
>                 ++cx;
>                 int const dci =d;
>                 auto const &dc = array[p][dci];
>                 auto const &fnih = dc.at(0);
>                 std::string const ni = get_ni(fnih, p);
>                 std::string const id = "ID_" + std::to_string(dx++) +
> std::to_string(cx++);
>                 std::cout  << "i " << ni << " <- " << id; //set
> breakpoint here
>                 res += res;
>             }
>         }
>     }
> 
>     return res.size();
> }
> 

-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University