[PATCH 4/5] Support backtracing through elfutils (#70746)

[Jasper St. Pierre]

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
<jan.kratochvil at redhat.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131030/63428ae7/attachment.html>