Hi, > 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.
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 > Debian-specific. 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 > __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. -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
