Re: [Linux-ia64] Unwind problem for __attribute__ noreturn

[Cary Coutant <cary@cup.hp.com>]

>Anyhow, I'll re-read the unwind conventions when I'm back at work.
>Either the document answers this question unambigiously and one of the
>existing unwinder implementation is wrong, or it doesn't answer the
>question, in which case we need to pick one solution and work towards
>clarifying this point in the manual.

I'll admit up front that the unwind conventions do not answer this 
question explictly, and they should.

The unwind conventions, however, are built on the assumption that the 
return pointer can always be used to determine the unwind state of the 
caller, whether that return pointer was generated by a br.call 
instruction, or through some equivalent assembly code.

Anyone using an assembly coding trick to make the return go somewhere 
other than immediately after the call must bear the responsibility of 
ensuring that the unwind information is correct.

In the case of a call to a "noreturn" procedure, I'll offer the opinion 
that having the unwinder decrement the rp is not correct. Two solutions 
immediately come to mind:

1. Emit a bundle of nops following the call. I understand that this is at 
odds with the goal of being able to describe fully-optimized code, but it 
seems like a rare enough case and a small enough penalty that we could 
live with it.

2. Turn the call into a tail call. Thus, in a call chain A calls B calls 
C, where C is the noreturn procedure, B would instead branch to C, making 
it look like A called C. You have to deallocate B's memory stack frame, 
so the bundle of nops may actually be more attractive unless B doesn't 
actually have a memory stack frame -- but it's also possible that the 
deallocation could be accomplished in spare instruction slots. C would 
simply take over B's register stack frame. As noted in the runtime 
document, tail calls can be done only when all arguments are in registers.

-cary