Ryan Johnson
2013-05-27 14:11:07 UTC
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
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