From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cary Coutant Date: Wed, 21 Mar 2001 18:48:54 +0000 Subject: Re: [Linux-ia64] Unwind problem for __attribute__ noreturn Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-ia64@vger.kernel.org >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