RFC: stack trace generation

Tue Aug 3 18:10:00 GMT 2004

Boehm, Hans writes:
 > Note that there is some interaction here with the heap debugging
 > patch (which is still not in the tree). In debug mode, the garbage
 > collector likes to put a stack trace in every object, which makes
 > stack traces much more performance critical. Frame-pointer-based
 > unwinding seems OK. David Mosberger's libunwind would probably
 > also be OK, though slower, since it does a fair amount of caching.
 > I haven't looked enough at dwarf2-backtrace.cc to see whether it
 > could be used directly.
 > 
 > Currently the GC usually does its own unwinding on X86. Since heap
 > debugging currently requires a different build anyway, it would be
 > OK to just enable frame pointers (on X86) for those builds.
That seems sensible. However, on many targets we won't ever be
building with frame pointers, so this won't be possible.
A caching version of backtrace() sounds like a nice idea. Maybe not
even all that hard? I'm not sure.
Andrew.