FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-01-2010, 06:03 PM
Florian Weimer
 
Default Better tracebacks for C/C++ (and probably Ada & Fortran, too)

* 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 04:01 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org