RE: [libunwind] backtrace on EM64T

[Yeshurun, Meir]

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?

Thanks again,

Meir

-----Original Message-----
From: Nathan Froyd [mailto:address@hidden 
Sent: Tuesday, November 08, 2005 9:01 PM
To: Yeshurun, Meir
Subject: Re: [libunwind] backtrace on EM64T

On Tue, Nov 08, 2005 at 07:10:41PM +0200, Yeshurun, Meir wrote:
> The GNU C backtrace() function is much slower on EM64T than it is on
32
> bit platforms (about a 1000 times slower). 
> 
> Is there a good reason for this slowness? Will an implementation of a
> backtrace function using the libunwind API also be much slower on
EM64T?

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.

These same considerations apply to libunwind as well.
-- 
Nathan | From Man's effeminate slackness it begins.  --Paradise Lost

The last good thing written in C was Franz Schubert's Symphony Number 9.
                                               --Erwin Dieterich