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

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

* Daniel Jacobowitz:

> On Sun, Jul 26, 2009 at 12:42:46AM +0200, Florian Weimer wrote:
>> 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.
>
> Can't you do this just by forking addr2line and providing a shim layer
> that knows shared library load offsets?  That saves you the really
> grotty bits.

Thanks for the suggestion.  At least for tracebacks on crashes, this
seems to be an approach which works really well.  addr2line can even
generate virtual frames for inlined functions.

There are some drawbacks, though: addr2line doesn't print a separator
if it generates multiple frames, so it is necessary to invoke it with
a single address if you want to use the inlining data.  Resolving
symbols in libstdc++ doesn't work automatically for some reason (I
have to pass the /usr/lib/debug file as a workarond).  addr2line on
libstdc++ locations is quite slow, it adds a noticeable delay to the
traceback printing.  The build root/relative path distinction
sometimes present in the DWARF debugging information is not preserved.
There does not seem to be much control over the demangling; for
instance, I would rather use the plain, fully-qualified function name
(without argument types) if source line information is also available.

And there's the fundamental issue of spawning a child process from a
library inside a multi-threaded program.  If this happens due to a
globally unhandled exception, this does not matter, but it also means
that this facility is not as a general-purpose as I'd want.

But all in all, addr2line is a win.