It's been a couple of decades since I was involved with DWARF (via bfd) but it's a static description language, even version 5 which I just looked over.
In theory you could provide code to run at runtime to figure out what a variable's value would have been had it not been optimized away. Instead of putting an executable language into DWARF the compiler could emit helper functions to be called by the debugger on arguments (pc, source line, some predecessor values). These could be emitted in an executable section stripped when the debugging info is stripped. The compiler actually has all the info it needs to generate such functions, but writing this code would be quite tedious.
gcc's debugging of optimized code is good enough that I pretty much always debug -g -O3 -... -- my bugs are rarely so subtle that this would obscure a problem!
One fun bug / issue I’ve been working on recently is that clang / llvm-mc (the llvm assembler) don’t handle dwarf data the same way as gcc. This can creat some issues if you’re using gcc on OS X, where the system assembler IS the llvm assembler. Even after this, there’s other misadventures with having dwarf data pass validation with the Apple/llvm linker.
My context is making sure that the main Haskell compiler, ghc, has an approximately 15 percent faster runtime system on OSX with c code built with GCC than with Clang. So I’ve been tracking down how to how to continue supporting that build combo while making sure dwarf / gdb suport in Haskell still works.
Being able to provide for a debuggable release build feels like an art to me. The more advanced the optimizations, the harder the task gets. Bugs that only appear only in release builds are some of the worst, so we probably can't give up on these efforts.
Yes. I set that up at work and the core dumps of release binaries became infinitely easier to debug. One thing I noticed with gcc and optimised release binaries is that the debug information gets incredibly large the more you optimise. With -Os and a handful of binaries totaling about 50MB, you can end up with a Gigabyte of debug information. That quickly filled up our build server drives.
In theory you could provide code to run at runtime to figure out what a variable's value would have been had it not been optimized away. Instead of putting an executable language into DWARF the compiler could emit helper functions to be called by the debugger on arguments (pc, source line, some predecessor values). These could be emitted in an executable section stripped when the debugging info is stripped. The compiler actually has all the info it needs to generate such functions, but writing this code would be quite tedious.
gcc's debugging of optimized code is good enough that I pretty much always debug -g -O3 -... -- my bugs are rarely so subtle that this would obscure a problem!
My context is making sure that the main Haskell compiler, ghc, has an approximately 15 percent faster runtime system on OSX with c code built with GCC than with Clang. So I’ve been tracking down how to how to continue supporting that build combo while making sure dwarf / gdb suport in Haskell still works.
https://ghc.haskell.org/trac/ghc/ticket/15207