RE: [libunwind] backtrace on EM64T

[Yeshurun, Meir]

Hi,

I failed to grep dwarf_cie_t.

Anyway, I thought the cache should be ip -> dwarf_reg_state. Does that make 
sense?

Dwarf_reg_state (defined in dwarf.h) looks like the equivalent of the cached 
scripts in ia64 because it shows how to restore the registers.

BTW, DWARF unwind information is explained quite well in the DWARF 
specification document (in case anyone doesn't know this).

Meir


-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of David Mosberger-Tang
Sent: Tuesday, November 22, 2005 6:22 AM
To: Arun Sharma (अरुण)
Cc: Keith Owens; Yeshurun, Meir; Nathan Froyd; address@hidden
Subject: Re: [libunwind] backtrace on EM64T

On 11/21/05, "Arun Sharma (अरुण)" <address@hidden> wrote:

> Through a quick grep of the sources, I can't locate anything
> problematic. mempool.h suggests that this is a design guarantee.
>
> So I'm assuming that this is a non-problem for the userspace libunwind.
> Please let me know if you think otherwise.

User-space libunwind assumes that mmap() doesn't acquire any locks so
that's what it's using.  Of course, via dynamic linking magic,
somebody could redefine mmap() to something that does acquire locks,
but there isn't much we can do about that (doing a syscall directly
from libunwind might be an option, but it's non-portable and could
potentially cause other problems).

BTW: You mentioned sigprocmask() showing up high in the profile.  With
caching, that should pretty much disappear (assuming you have
libatomic_ops installed at configure time).

As for the caching in DWARF2: IIRC, the structure you want to cache is
dwarf_cie_t.

  --david
--
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536