Re: Better tracebacks for C/C++ (and probably Ada & Fortran, too)
> 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
> 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.
gnatbind could be instructed (-E) to store non-symbolic traceback in exception
occurrences, which would be printed out as a list of addresses of calls, which
could then be translated into source lines by addr2line tool from binutils.
There is also Call_Chain() procedure for Ada which records the a complete
stack traceback and is part of the GNAT.Traceback package, which I suspect
probably operates in a way similar to your library operation, though I have
never used that before.
> Due to the peculiar combination of libraries, it's somewhat
Perhaps the authors of `diagnostics' source package (available in Debian)
would be interested to include your library.
> 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 <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.
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>