Whoops, I misspoke when I talked about libbacktrace. I meant libunwind all throughout, since that's what Xorg uses right now.
Should we work on making the elfutils backtrace API more like libunwind / libbacktrace, and simpler to embed? Right now we have support code in glib that forks off gdb and feeds it commands over a stream, which is horribly slow and often deadlocks your app; I was planning to replace it with libunwind. Should we focus on porting libbacktrace / libunwind to elfutils, and have one simple API for this? On Wed, Oct 30, 2013 at 2:26 AM, Jan Kratochvil <[email protected]>wrote: > On Wed, 30 Oct 2013 03:13:28 +0100, Jasper St. Pierre wrote: > > This API is really bad compared to what's provided by > > libbacktrace, which is super simple. > > libbacktrace is not a real unwinder, it runs on top of libgcc backtrace() > you > currently use. Which is fine for xorg. > > libbacktrace even supports displaying inlined functions, file:lineno and > automatic C++ symbols demangling. > > libbacktrace seems a better choice than both elfutils and libunwind for > xorg > addr->symbol resolution (+its new inlined frames). Just I find a blocker > for > xorg that libbacktrace is currently not packaged in any distro AFAIK; that > could be sure fixed. > > > > This also seem to require callbacks that have "Linux" in the name. > > True, libunwind contains src/os-freebsd.c and src/os-hpux.c where I expect > elfutils will fail to find /proc/PID/maps expecting Linux OS. > I could implement the few lines of HPUX/FreeBSD image finding code into > elfutils if that would be the only blocker of this patch. > > > > Why are we trying to get rid of libbacktrace, > > It contained (and according to my tests it still contains) many unwinding > bugs > plus most of its code is a duplication of elfutils (which need to be > maintained > anyway). That is Fedora (rather so far mine) point of view, sure not > xorg's. > > > Regards, > Jan > -- Jasper
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
