Re: [Query] Re: dwarf unwinder (only works on i386/x86_64)

[Mark Wielaard <mjw@redhat.com>]

Hi,

Roland already answered most of the questions. Some time ago I wrote
some high level overview of all the moving pieces related to unwinding.
Maybe someone finds that useful:
A while ago I tried to summarize some of these issues:
http://gnu.wildebeest.org/diary/2007/08/23/stack-unwinding/

On Tue, 2009-04-28 at 11:17 -0700, Roland McGrath wrote:
> > ii. This section seemingly appears to be a better bet than DWARF to base 
> > the unwinder on--- because a ".debug_frame" based unwinder might not be 
> > useful in case of a kernel complied without debuginfo.
> 
> It is a somewhat hairy subject.  But in short, this is not so in current
> kernels.  That is not entirely apropos, because it's only the situation for
> the kernel, and there are also user binaries to consider.  There it is an
> even more complex subject.  The overall answer is that the answer is complex,
> but potentially both sections are involved.

The original choice for using debug_frame was because it was always
available (since we required debuginfo already) and it was complete. GCC
4.4 changed this though (and the uprobes_ustack.exp test does indeed
fail when build with gcc 4.4). With that version .debug_frame is no
longer complete, if unwind data is emitted into .eh_frame, it is not
emitted into .debug_frame (so no duplication) and only when .eh_frame is
not emitted, .debug_frame is emitted. So we have to start doing
something more clever. Defaulting to .eh_frame (at least for user space)
might be a good idea, and maybe then combining the two tables (and maybe
creating our own search table).

.eh_frame and .debug_frame are encoded slightly differently, but
supporting both is not hard.

Cheers,

Mark