[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> 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>

Reply to: