No subject

wrong thing for functions where the entry point is not at the start of
the function body (or where there are loops or multiple entry points)
-- I expect such instances to be pretty rare though, and this should
never happen for C.

Tricks like this are no good for reconstructing what happened on the
path up to an unexpected event like an exception, though.  This is
possible only when certain assumptions are made and the faulting 
function has a sufficiently simple structure.  This can work most of
the time, but it's hard to make it watertight -- this is one reason why
backtracing in gdb is still far from foolproof.

Alternatively, we would need to use some other frame description format
such as DWARF, which would involve building everything with debug, and
keeping the .debug_frame content (possibly with some filtering/post-
processing).  Unwind annotations in .S files would presumably need to be
rewritten to use the .cfi_ dierctives instead of the ARM-specific
directives in order for this to work everywhere.  Apparently there were
some patches around for using DWARF for backtracing in the kernel some
years ago, but they didn't get merged.



...all of which means that making unwinding work _perfectly_ probably
involves significant pain, at least for Thumb-2.

I guess the question would be: how many failed backtraces are we getting
right now?  Is the current unwinder behaviour "good enough"?

Cheers
---Dave