3 ms·

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 optimiz

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).

DoofusOfDeath 6y ago
> 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.
- xxpor 6y ago
  I can't say I've ever seen that (I still use dwarf 3 however). Is there a certain pattern to it?
  - jmorse2 6y ago
    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).
    - xxpor 6y ago
      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.
  - DoofusOfDeath 6y ago
    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.
    - saagarjha 6y ago
      Does "-g" and no optimization flags not work?
    - slavik81 6y ago
      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-debugger-tuning https://clang.llvm.org/docs/UsersManual.html#controlling-deb...

DoofusOfDeath 6y ago

> 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.

xxpor 6y ago
I can't say I've ever seen that (I still use dwarf 3 however). Is there a certain pattern to it?
- jmorse2 6y ago
  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).
  - xxpor 6y ago
    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.
- DoofusOfDeath 6y ago
  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.
  - saagarjha 6y ago
    Does "-g" and no optimization flags not work?
  - slavik81 6y ago
    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-debugger-tuning https://clang.llvm.org/docs/UsersManual.html#controlling-deb...