title: What flags or environment variables can I pass to Clang to get maximum debugging on both BSD and Linux?
body: <p>I'm interested in answers, approaches, and ideas out of the box.  At a high level, the main page is pretty sparse and they mainly list <code>-g</code>, with one level, suggesting that <code>-O0</code> is also either very helpful or essential.</p>
  
  <p>But I'm wondering what other clang flags can be given to give maximum debugging.  Is there an equivalent to gcc's <code>-ggdb3</code> which includes some of the source or annotations directly in the object output?  Or could there be?  Is it possible and helpful to recompile the OS and its original libraries to have debugging (and if so, if I'm using Debian, can I have it write the debugging into the main .deb package instead of putting a separate debugged .deb package which stores debugging data in <code>/usr/lib/debug</code>?)?  Will a static build of a binary affect the ability to see a good stacktrace?  And is there anything that needs to be done to ensure that addr2line works well?  Is it needed to compile all libraries (even glibc) with clang to get the maximum debugging benefit?  I note that there is a project to recompile Debian with clang, and otherwise am open to a distribution that does so or otherwise places emphasis on debugging.</p>
  
  <p>On Linux there are also options like an <code>LD_PRELOAD</code> set to <code>/lib/libSegFault.so</code>, or a set of <code>LD_LIBRARY_PATH</code> reassignments to <code>/usr/lib/debug</code> instead of the usual /usr/lib location (including redirecting libc itself to the debugged version).  Is there a central place or external sources for answers to this question of how to enhance debuggability of a binary?  The bigger mystery is clang, since I see in the long gcc man page that there are various options which can increase debugging (or reduce optimisations), but on the other hand the documentation for clang only shows a smaller set.  It's possible that clang will accept more options than given, including gcc flags (which may either translate to a no-op or to more debugging - hard to tell without a canonical source of information).</p>
  
  <p>Also from a package build perspective, since an external package may not respect <code>CFLAGS</code>, I've redirected <code>/usr/bin/strip</code> to be a no-op command that always succeeds, but other ideas on ensuring compliance are suggested (I believe that pkgsrc does a good job of wrapping gcc and the linker in shell scripts - useful to insert mandatory flags).  Also there may be various ld options that can be passed to increase debugging of the outputted target.  Also, it's quite possible that BSD (including FreeBSD 10, based upon clang) may have a different linking architecture which could make it easier to request and find debugged symbols in the generated libraries and executables.</p>
  
  <p>To take debugging more broadly defined, I've set <code>LD_WARN=yes</code>, <code>LD_DEBUG=unused</code>, <code>SEGFAULT_SIGNALS="all"</code>, <code>LD_PRELOAD=.../libSegFault.so</code> (as mentioned above), and <code>LD_BIND_NOW=yes</code>.  Also I believe I can prefer that gcc search for libraries in /usr/lib/debug - above the standard search paths using strategic <code>-B</code>s.  Also, using <code>--whole-archive</code> for a static build might ensure that more objects are included in the linked output.  There's also <code>ulimit -c unlimited</code>, and on Linux a nice way to differentiate core files like:</p>
  
  <pre><code>sysctl -w kernel.core_pattern="core.%t.SIG-%s.PID-%p.ID-%g-%u.%h.%E"
  </code></pre>
  
  <p>For gcc I've used and seen flags like: <code>-O0 -fno-omit-frame-pointer -fverbose-asm -ggdb3 -mno-omit-leaf-frame-pointer -mtune=generic -fvar-tracking -D_GLIBCXX_DEBUG=1 -frecord-gcc-switches -femit-class-debug-always -fmath-errno -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-types -fno-merge-debug-strings -mieee-fp -mtune=generic -static-libgcc -fexceptions -fvar-tracking -fbounds-check -rdynamic -UNDEBUG -DDEBUG=1 (-ffreestanding -static-libgcc -pass-exit-codes) -fno-stack-check</code> (since I believe I've read that the latter can interfere with debugging)</p>
  
  <p>Other flags are there for other reasons but the emphasis is to be on maximum debugging.  With all or most of the above, it's unclear to what extent clang would support or use there, or whether there are other options.</p>