gcc-4.8 and libbacktrace

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

Hi all,

FYI, gcc-4.8 includes a new libbacktrace.a (BSD-licensed, I believe) 
that uses dwarf unwind info to accurately unwind the stack. It's thread 
safe, doesn't call malloc, and works properly from signal handlers. GCC 
uses it internally to generate its own backtraces on ICE, and go/fortran 
use it to generate their backtraces. The library itself is virtually 
stand-alone other than a few stray header files from the gcc sources 
(according to its developers). I've confirmed (on linux) that the 
libbacktrace.a compiled as part of gcc-4.8 works fine when linked 
against code generated by gcc-4.6, for example. The only small annoyance 
is that libbacktrace doesn't get installed with gcc, so you have to 
dredge it out of the build dir yourself.

At some point there was concern about unwind tables bloating the 
executable, but IIRC the x86_64 ABI requires them anyway, so 64-bit 
cygwin won't see any difference (iirc, the tables were only a few 
hundreds of kB last time I checked 32-bit cygwin).

(I realize that SHTDI, and that somebody won't be me... just wanted to 
throw the idea out there in case anybody feels an itch)

Caveat #1: Technically, libbacktrace is ELF-only, so it might take a 
touch of fiddling to teach it about cygwin's object format. I had the 
impression that cygwin object files are basically ELF in disguise, 
though, so it shouldn't be hard to close the gap.

Caveat #2: the library caches all debug info of all loaded objects the 
first time it's called, which could bloat the runtime image and also 
misses dlopen/dlclose calls that arrive afterward. It might be possible 
to disable caching for one-off uses, though (or cygwin1.dll could just 
tweak its dlopen/dlclose to invalidate caches).

Thoughts?
Ryan