
Comparing the Quality of Debug Information Produced by Clang and Gcc - mpweiher
https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html
======
gumby
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!

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

[https://ghc.haskell.org/trac/ghc/ticket/15207](https://ghc.haskell.org/trac/ghc/ticket/15207)

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

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

