libunwind-devel
[Top][All Lists]
Advanced

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

Re: [Libunwind-devel] Interest in .debug_frame support?


From: Arun Sharma
Subject: Re: [Libunwind-devel] Interest in .debug_frame support?
Date: Wed, 3 Oct 2007 08:20:08 -0700

On 10/3/07, Daniel Jacobowitz <address@hidden> wrote:
Corey Ashford asked in February whether there were any plans for
.debug_frame support.  I have a similar question - is there any
interest in including .debug_frame support?

I've been looking at a system where I'd like to have backtraces during
debugging (from memory allocation debuggers, et cetera). 


This is exactly how we use libunwind today.

http://code.google.com/p/google-perftools/


 This is a
debugging feature, so I'm willing to put extra data on the target
during it, probably using .gnu_debuglink to point at separate files.
But the overhead of .eh_frame is not acceptable.

Can you describe what are the overheads you're worried about? Just the binary size?

Since we tend to think that stack unwinding should be on for all binaries at all times, this hasn't been a big issue for us. What is more interesting is:

a) Performance - unwinding code can't perturb the performance - even at low sampling rates.
b) Correctness - unlike out-of-process debuggers, we don't have the luxury of dereferencing bad pointers and getting EFAULT.

One problem with .eh_frame is that we depend on dl_iterate_phdr() to locate it. This doesn't work for statically linked binaries and other use cases. Reading the ELF binary directly would make it work better.

 -Arun


reply via email to

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