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 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
