Re: Does -Og work well?

[Nick Savoiu <savoiu@yahoo.com>]

Yes, I've done many of these in my debugging.

My "beef" was with the GCC documentation pointing to -Og as the 'recommended' setting for debugging code. While it might improve code speed it makes debugging much harder which is not what one would expect given the documentation's rosy picture.

Nick




On Thursday, October 14, 2021, 12:09:17 AM PDT, David Brown <david.brown@hesbynett.no> wrote: 





On 11/10/2021 19:47, 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.

> 

Debugging is an art, not a science - there is no single correct answer.
And there is no such thing as code that is clearly and neatly written
in the source, optimised well in the object code, and easy to debug.
Pick two of these three, and you might manage it.

"-Og" can be a good start.  It does a little less re-arranging of the
code than "-O2 -g" does.  In my debugging, I sometimes go down from my
usual "-O2" (with additional options) to "-O1", but I never bother
trying "-O0".  Without any optimisation, all meaning in C++ code is lost
in endless calls to functions that don't actually /do/ anything at the
object code level (though they have meaning for the source), and you
can't follow the generated assembly because every second instruction is
moving something into or out of the stack.  (Details here may vary by
target architecture, of course.)

When you need to debug a section of code at a low level, you often need
to add extra bits to the code as an aid.  Adding a few volatile
variables to hold intermediary values is often useful - and volatile
accesses are convenient places to put breakpoints.  The odd "no_inline"
attribute on key functions, or pragmas to turn off inlining or lower
optimisation for a particular section of code.  A compiler memory
barrier "asm volatile(:::"memory");" ensures that data and variable
accesses are separated on either side, letting your debugger clearly see
the state of variables at the point.

Of course, sometimes adding this kind of thing changes the nature of the
issue and the problem disappears - but then you have gained valuable
insight into what might be causing the problem.

David