Better tracebacks for C/C++ (and probably Ada & Fortran, too)

[Florian Weimer <fw@deneb.enyo.de>]

I've built a small proof-of-concept library which creates Java-style
tracebacks for C and C++ programs.  In contrast to libc's backtrace()
function, it uses DWARF debugging information when available, so the
output is generally quite useful.  Debugging information is extracted
from the main executable and any loaded DSOs, or from the shadow debug
tree in /usr/lib/debug.

The whole thing is a bit of a mess because it links together ld.so,
libgcc's unwinder, libdwarf and the demangler from libiberty.  The
advantage is that it should work with anything which generates stack
frames compatible with _Unwind_Backtrace() (which likely includes all
architectures for which we've got GCJ support) and DWARF debugging
information.  No additional compiler-generated tables or special
exception calsses are needed, so it generally works out of the box
(provided you compile with "-g").  This is in contrast to stack
tracebacks in GCJ; the downside is that my implementation is quite a
bit slower, but unlike Java, it's only called when there is actually
an unhandled exception which is about to terminate the program (Java
creates a backtrace each time a throwable object is initialized).

Some clean-up is still needed (mainly to make it more robust with
questionable DWARF data, e.g. in the presence of circular debugging
information).

I'm now wondering whether something like this already exists (I
couldn't find anything, though).  I'm also not sure where to put this.
Due to the peculiar combination of libraries, it's somewhat
Debian-specific.

The output currently looks like this, and is recognized by Emacs:

Exception std::runtime_error: foo
        at test_traceback(test/test-traceback.cpp:18)
        at main(build/test/run.cpp:13)
        at __libc_start_main(/home/aurel32/tmp/eglibc/eglibc-2.9/csu/libc-start.c:222)
        at <unknown>(../sysdeps/x86_64/elf/start.S:113)

SIGBUS/SIGSEGV could probably handled in a similar way, but the bulk
of the work should probably done in a fresh subprocess, with
uncorrupted data structures.