I wonder if the error message could just be better. Instead of using the excuse that the variable has been &quot;optimized away&quot;, maybe gdb should just say it &quot;cannot determine variable value due to optimization&quot;.

Could you clarify this comment a bit? Does GDB ever use current register contents to satisfy a request for a variable, or does it only use a value saved to the stack? That is, is the problem that you don&#x27;t know when the register value is no longer valid, or that GDB doesn&#x27;t actually associate the value with a register at all?

(I wrote a bunch of gcc&#x27;s initial support for optimized code debugging, as well as the initial associated gdb support for evaluating location lists and expressions, which is what makes this all work under the covers)Given the invariant of &quot;debug info does not affect optimization&quot;, you end up with plenty of cases where your only possible choices are &quot;give the user a possibly wrong value for the variable&quot; or &quot;say the value does not exist anymore&quot;.Most of the time, the latter is done instead of the former.You also unfortunately cannot just mark them so the debugger tells you &quot;this may be wrong, it may be right, good luck&quot;.Historically, compilers tried doing the former, users complained enough that they switched to doing the latter.

Regarding MSVC, just if you don&#x27;t know already, you might want to try &#x2F;Zo (formerly &#x2F;d2Zi+). [1][1] <a href="https:&#x2F;&#x2F;msdn.microsoft.com&#x2F;en-us&#x2F;library&#x2F;dn785163.aspx" rel="nofollow">https:&#x2F;&#x2F;msdn.microsoft.com&#x2F;en-us&#x2F;library&#x2F;dn785163.aspx</a>

More times than I&#x27;d like, I&#x27;ve encountered GDB refusing to show the value of a variable, claiming it&#x27;s &quot;optimized away&quot;.No, it&#x27;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 &quot;optimized away&quot; too, but the experience of debugging optimised code could definitely use a lot of improvement.(This isn&#x27;t exclusive to GCC&#x2F;GDB either --- I&#x27;ve seen the same with MSVC and Visual Studio, but in my experience the latter tends to be somewhat better.)

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&#x27;s link-time optimization flags are chosen, and what happens when they&#x27;re absent. And most importantly, why -O0 has an impact on LTO when it&#x27;s passed at link-time, but eg. -O2&#x2F;-O1 at compile time.

I believe GP is not talking about thread parallelism, but rather the compiler-controlled instruction reordering. Compilers typically reorder instructions in the hope that it will improve performance. For example if you have v+=2, the compiler can choose to load v into a register, and then continue with the rest of the statements, and ten instructions later perform the actual addition and store it back into memory.

Visual Studio has something called &quot;Parallel Stacks&quot; [1] which shows a graph of all the stacks of every thread of the application. It&#x27;s very powerful when debugging multithreaded code.[1] <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;visualstudio&#x2F;debugger&#x2F;using-the-parallel-stacks-window" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;visualstudio&#x2F;debugger&#x2F;using...</a>

<a href="https:&#x2F;&#x2F;ftp.gnu.org&#x2F;old-gnu&#x2F;Manuals&#x2F;gdb&#x2F;html_node&#x2F;gdb_24.html" rel="nofollow">https:&#x2F;&#x2F;ftp.gnu.org&#x2F;old-gnu&#x2F;Manuals&#x2F;gdb&#x2F;html_node&#x2F;gdb_24.htm...</a>

LLDB does this, and it lets you jump between threads. I’m not sure if GDB supports this.

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

I appreciate your comment and its perspective.I spend a lot of my time optimizing code switching between,01 and 03.I am genuinely very worried about the trade-off between optimization and pragmatism.At the same time, I am limited. This very useful analysis would help me a lot if it providied an executive summary.Non-linear debug builds are obviously harmful.

I used to send mails like this at work to people somewhat often, selecting mailing group according to subject. I&#x27;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&#x27;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&#x27;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&#x2F;-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&#x27;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&#x27;ve probably looked at the gcc manual and noted that there&#x27;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&#x27;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&#x2F;or if you only you had somebody on staff who could just try this stuff out and write you a summary! But you don&#x27;t, and you don&#x27;t, and you don&#x27;t, and you have a product to finish anyway...So this document might at least be mildly interesting.

I think, after scrolling down to the bottom, it&#x27;s meant to be a look at what passes are unnecessarily impairing debugging information.

the point was to document current shortcomings in debug info generation and identify opportunities for improvement. the executive summary is that there are many ;-)

I kept reading and reading wondering, what is the point of this document? I make it 1&#x2F;3rd through.It seems well informed, but it lacks any coherent structure. And throughout I couldn&#x27;t deduce what the point was. Like a well educated rant.

Why would you ever need to go below the abstraction level of your high level language to debug.If you&#x27;re going down into registers, you&#x27;re obviously debugging the wrong way.You don&#x27;t need printf&#x27;s if you write directly to your screen which is easy to do.

sometimes you might not have even printf available (very low-level software comes to mind) so you&#x27;re limited to using registers. Without a debugger it would be a nightmare.

&gt; except it&#x27;s much faster to put a few breakpoints than to recompile your code each time you want to add&#x2F;remove a logging statement.that reeaaallly depends. I had cases where adding a printf and recompiling would take mere seconds and a gdb startup on the order of 3 to 4 minutes because recompiling only changes one shared library while GDB has to load all of them.

If you don&#x27;t use a debugger, you don&#x27;t need an IDE either.A text editor and a compiler is all you need.That simplifies your programming interface a lot.

except it&#x27;s much faster to put a few breakpoints than to recompile your code each time you want to add&#x2F;remove a logging statement.

If you approach debugging in a very minimalist way,you should never use a debuggerbecause it only serves to complicate thingsusing the I&#x2F;O subsystem to debug your programis a far more efficient way to debug.If you do things this way,you orthogonalize the optimization side of your compilerfrom the mess created by trying to assist the debugging processvia the rather complex and intrusive (from the compiler&#x27;s perspective) component called the debugger

GCC gOlogy: studying the impact of optimizations on debugging