From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Mosberger Date: Wed, 21 Mar 2001 19:13:15 +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 >>>>> On Wed, 21 Mar 2001 10:48:54 -0800, Cary Coutant said: >> 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. Cary> I'll admit up front that the unwind conventions do not answer Cary> this question explictly, and they should. OK. Cary> The unwind conventions, however, are built on the assumption Cary> that the return pointer can always be used to determine the Cary> unwind state of the caller, whether that return pointer was Cary> generated by a br.call instruction, or through some equivalent Cary> assembly code. Yes, that was certainly my _impression_ when reading the unwind conventions. It would be good to make this explicit, though. Cary> Anyone using an assembly coding trick to make the return go Cary> somewhere other than immediately after the call must bear the Cary> responsibility of ensuring that the unwind information is Cary> correct. Yes, the kernel does that. Cary> In the case of a call to a "noreturn" procedure, I'll offer Cary> the opinion that having the unwinder decrement the rp is not Cary> correct. Two solutions immediately come to mind: Cary> 1. Emit a bundle of nops following the call. I understand that Cary> this is at odds with the goal of being able to describe Cary> fully-optimized code, but it seems like a rare enough case and Cary> a small enough penalty that we could live with it. OK. But I'd rather see the compiler emit a "break 0" instead of a "nop 0". With the former, when a noreturn function unexpectedly returns, it will a generate a SIGILL signal with code ILL_ILLOPC (illegal opcode) instead of silently executing wrong code. Cary> 2. Turn the call into a tail call. Thus, in a call chain A Cary> calls B calls C, where C is the noreturn procedure, B would Cary> instead branch to C, making it look like A called C. You have Cary> to deallocate B's memory stack frame, so the bundle of nops Cary> may actually be more attractive unless B doesn't actually have Cary> a memory stack frame -- but it's also possible that the Cary> deallocation could be accomplished in spare instruction Cary> slots. C would simply take over B's register stack frame. As Cary> noted in the runtime document, tail calls can be done only Cary> when all arguments are in registers. Yes, I considered that, too. But I think the biggest savings of "noreturn" comes precisely from not having to bother to drop the current call frame, so emitting an extra bundle containing "break 0" is probably a better approach. --david