Re: [libunwind] backtrace on EM64T

[Arun Sharma]

Yeshurun, Meir wrote:
> Thanks for the quick reply, Nathan.
>
> I don't know much about DWARF2 unwind information (yet). Suppose however
> that you are backtracing many times into code from the same set of
> shared or executable objects. Is it possible to limit the penalty to an
> initialization phase in which the DWARF2 information will be read, and
> allow subsequent backtraces into the same objects to be done quickly?

I can't seem to find a noticable improvement.

[ 3.4 GHz P4 ]

$ tests/Gperf-simple
unw_getcontext : cold avg=  329.018 nsec, warm avg=  309.944 nsec
unw_init_local : cold avg=  228.882 nsec, warm avg=   40.531 nsec
no cache        : unw_step : 1st= 2781.550 min= 1961.844 avg= 2138.138 nsec
global cache    : unw_step : 1st= 2388.727 min= 1970.927 avg= 2131.012 nsec
per-thread cache: unw_step : 1st= 2534.049 min= 1943.679 avg= 2131.551 nsec

> I would imagine this is because on 32-bit (ia-32) platforms, backtrace()
> can simply follow frame pointers.  On 64-bit (x86-64) platforms,
> however,
> frame pointers are optional, so backtrace() has to decode DWARF2 unwind
> information--much slower than following frame pointers.  If you could
> ensure that you always had frame pointers in your 64-bit code, then
> backtrace() on both platforms would be equally fast.

I've found that when I specify -fPIC (needed for shared libs) on x86-64, 
the compiler omits frame pointers. So you'll always end up using the 
dwarf2 based unwinder, unless you want to do statically linked binaries.

        -Arun