GCC gOlogy: studying the impact of optimizations on debugging

I kept reading and reading wondering, what is the point of this document? I make it 1/3rd through.

It seems well informed, but it lacks any coherent structure. And throughout I couldn't deduce what the point was. Like a well educated rant.

Thanks for sharing. I wish there was a similar article regarding the different quirks of Link-Time Optimization and its effect on debugging, and how that impact has changed since GCC 4.x. Also, an explanation of how LTO's link-time optimization flags are chosen, and what happens when they're absent. And most importantly, why -O0 has an impact on LTO when it's passed at link-time, but eg. -O2/-O1 at compile time.

I used to send mails like this at work to people somewhat often, selecting mailing group according to subject. I'd typically have spent a while trying to figure something out, met with some success, and figured I might as well send a summary to anybody that could be remotely concerned. Maybe save somebody else the bother in future.

Most of the time, nobody cared. (Which is fine, I never did this stuff for no reason, the write-up was typically beneficial for me personally, and if nobody else cared, that's OK by me.) But the odd one would prove useful and end up getting re-forwarded multiple times, and that happened often enough that I kept doing it.

(I use the past tense because I do contract work these days, and that works differently.)

Leaving aside the justification for this sort of thing in general, and moving on to why you might be interested in this particular note: suppose you'd always just built your code at one of either -O0 (shit code, but works well with any debugger), -Os (slightly less shit code, debugging probably tolerable) or -O2/-O3 (decent code, but debugging is a pain - and I always knew the assembly language for every target! The people that only knew C++ had a devil of a time).

So this works, and you're used to it, and what better argument for anything could there possibly be. But you probably wondered whether you could do better, and with this in mind you've probably looked at the gcc manual and noted that there's this huge pile of other sub-options. What if you tweaked those, you wonder? Would that make things better? Would it make them worse? If you only had the time to investigate which would impede debugging, and which you could just pop into your debug build with impunity, safe in the knowledge that it wouldn't cause you any difficulty! If only you had the sort of more in-depth knowledge of compiler internals required to make this sort of judgement by yourself, rather than just go through the 500,000 combinations of options to try each one in turn! And/or if you only you had somebody on staff who could just try this stuff out and write you a summary! But you don't, and you don't, and you don't, and you have a product to finish anyway...

So this document might at least be mildly interesting.

More times than I'd like, I've encountered GDB refusing to show the value of a variable, claiming it's "optimized away".

No, it's sitting right there in a register, and I know that because I just stepped through, instruction-by-instruction, the code that computed its value. Fortunately it does not claim the register has been "optimized away" too, but the experience of debugging optimised code could definitely use a lot of improvement.

(This isn't exclusive to GCC/GDB either --- I've seen the same with MSVC and Visual Studio, but in my experience the latter tends to be somewhat better.)

What I'd appreciate is if GDB, when stopped during execution, could show _all_ of the source statements that are currently 'in progress' (for the common case under optimisation where the execution of several source statements are interleaved). I don't know how feasible that is, though.