Hacker News Reader

Comment by einpoklum | Hacker News Reader

A few items from the release notes that caught my attention:

* The debug information now has a feature which lets your debugger recover the value of an optimized-out value in certain (common) circumstances. I wish gdb and lldb pick on up this quickly and that it doesn't need you to specify anything explicitly.

* If you're doing JITing with LLVM, you can now run your code's static initializations (which apparently you couldn't before? :-O )

* Lots of RISC-V-related work (features, optimization improvements and bug fixes).

* Nothing new for PTX (the CUDA IR which you can use LLVM to generate).

View on HN

> The debug information now has a feature which lets your debugger recover the value of an optimized-out value in certain (common) circumstances. I wish gdb and lldb pick on up this quickly and that it doesn't need you to specify anything explicitly.

It drives me nuts when I compile code with "-ggdb -gdwarf-4 -O0" and gdb still reports some symbols as "optimized away". I hope the bullet point above refers to this.

I can't say I've ever seen that (I still use dwarf 3 however). Is there a certain pattern to it?

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?

Reply on news.ycombinator.com