Re: [Libunwind-devel] Backtrace performance on x86-64 based on Dwarf info

[Arun Sharma]

On Fri, May 30, 2014 at 3:42 PM, Milian Wolff <address@hidden> wrote:

>
> So... yes? But what does that have to do with the 0-IP I encounter at the
> end of a backtrace?
>

Only RBP=0 can indicate the end of call chain. We used to treat RIP=0
as an indication to stop the unwinding, but it broke a bunch of legit
use cases.

d04dc94 dwarf: ip == 0 should't terminate unwind

The problem here may be that various caches in the fast path (Gtrace.c
and src/dwarf/Gparser.c:rs_new()) ignore the RIP==0 case. This is
exacerbated by the calls to block signals.

We do have a --enable_block_signals config option. More info about it here:

9aa0d6d Allow caller to block signals.
84d4150 Allow caller to block signals.

If you can guarantee that signals are blocked on entry to libunwind,
we can optimize away the sigprocmask calls.

A longer term solution may be to teach the libunwind caches about
negative caching in general or the RIP==0 case in particular.

 -Arun