It's DWARF-5 only: variable values can be expressed in terms of a parameters value on entry to the function. Depending on the circumstances, that value can be recovered from further up the stack frame.

(Ninja edit: although tuning for GDB might coax LLVM to emit the pre-standardised form, without DWARF-5).

When I have to debug a production crash (compiled with -O3), that's usually what I do today. Basically, the value can be derived from something that's static/global, eventually. Now that I think about it though, I'm kind of surprised gdb hasn't done that for me historically, but maybe the debug info isn't detailed enough and I can do it just because I can read the actual source.

I don't recall. Sometimes doing a full rebuilt takes more a while, so my process goes something like this:

1) build with "-O0 -ggdb"

2) In a debug session, notice that a variable I want to inspect has supposedly been optimized away. Get extremely frustrated.

3) Rebuild with every debug-friendly flag I can conceive of "-O0 -ggdb -fno-inline -gdwarf-4 -fno-omit-frame-pointer ..."

4) IIRC, step 3 usually (but not always?) addresses the issue.

But long story short, I don't think I've ever pinned down the minimal requirements for avoiding the issue. Usually when I encounter this, I have bigger issues to deal with.

What difference does -ggdb make vs -g? I see it does extra 'tuning' of the debug output for GDB [1], but it's unclear what effect that might actually have.

[1]: https://clang.llvm.org/docs/UsersManual.html#controlling-deb...

Does "-g" and no optimization flags not work?