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