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
