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

[David Mosberger <davidm@hpl.hp.com>]

>>>>> On Wed, 21 Mar 2001 10:48:54 -0800, Cary Coutant <cary@cup.hp.com> 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