* 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
