Re: ARM problems with the exception unwinder

[Richard Earnshaw <rearnsha at arm dot com>]

> > The problem is that when cfa_reg is set to the frame pointer, the stack 
> > pointer value pushed on the stack is updated,
> 
> I think that's the bug.  How can that be right?  Surely the value pushed on
> the stack in the prologue shouldn't need adjustment?
> 
> When unwinding, we should always restore SP using the offset, never using
> the value saved in the stack.

Are you suggesting I need to create special stack frame when compiling 
__[re]throw that doesn't save the stack pointer?  If so:
 1) That's a pain, the prologue code is complex enough without this.
 2) It will make it nearly impossible for debuggers to backtrace through 
this, which makes setting a breakpoint on __unwinding_cleanup useless.
 3) It might not work with APCS variants that need to do stack-chunking 
(allocating discontiguous stack segments).

> > but when cfa_reg is the stack pointer, the value stored on the stack
> > isn't updated.  Then when we restore SP we get a number that may be right
> > or it may not -- there is no way to tell.  I think the correct thing to
> > do is that if there is a save slot for ustate.cfa_reg in mystate we
> > should update that value; then the only adjustment that should be applied
> > at the end is to add args_size for the initial caller to unwind any
> > pushed arguments.
> 
> No.  Usually a save slot for ustate.cfa_reg just means that the frame
> pointer was saved at the beginning of the prologue.  The code you reference
> in frame_dwarf2 refers to "saving" the CFA register after its value from
> the caller has already been clobbered with some value derived from SP.

So do we correctly restore the frame pointer when we have fp as the 
cfa_reg and we have an instruction of the form

	stmfd	sp!, {...., fp, ...}