[Libunwind-devel] Re: [PATCH 0/4] ARM enhancements

[Ken Werner]

Henrik Grindal Bakken wrote:
> Hi, Ken,

Hi Henrik,

Thanks for your feedback!

> We're using libunwind for providing stacktraces on crashes on a
> product running on ARMs (TI DaVinci).  Previously, I've been having
> problems with libunwind segfaulting if I don't have debugging symbols,

If there is no DWARF info libunwind falls back on the old ARM Procedure Call 
Standard to follow the call chain. Nowadays most people seem to use the ARM 
EABI so parsing APCS frames won't help. This is where the exception table 
parsing comes into play. As you noticed it is not ready for prime time 
yet (see below).

> but these patches look very promising indeed.  I can't really get it
> working, though.  It appears to not walk the stack at all, but always
> find the same frame.

With this patch applied the 'cursor' consists of a dwarf_cursor and an 
arm_stackframe. The dwarf_cursor is used in case the unwind infos are 
provided via debug infos while the arm_stackframe is used in case unwind 
infos are provided through the .ARM.exidx and .ARM.extab sections. Since 
they are not synchronized you'll get the wrong data sometimes. For example, 
the unw_get_reg routine ignores the arm_stackframe and operates on the DWARF 
data that may not up to date. This is definitly not the users fault - 
libunwind should just work. I'm working on a patch that eliminates the use 
of the arm_stackframe, the vrs and the two helper routines 
arm_exidx_frame_to_vrs and arm_exidx_vrs_to_frame that convert between them. 
The goal is to have the extbl parser operate on the dwarf_cursor directly. 
In theory this should allow to also mix DWARF- and extable-frames.

Regards
Ken