[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libunwind] backtrace on EM64T

From: Arun Sharma
Subject: Re: [libunwind] backtrace on EM64T
Date: Tue, 08 Nov 2005 12:07:25 -0800
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051011)

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,
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]