Re: dwarf-frame.c question

[Jim Blandy <jimb@redhat.com>]

Richard Henderson <rth@redhat.com> writes:

> On Mon, Jun 02, 2003 at 07:03:56PM -0500, Jim Blandy wrote:
> >     The DW_CFA_GNU_unwind_from_noreturn instruction indicates that the
> >     current set of rules applies only when the current location was
> >     reached by unwinding a frame called by this one, not when it was
> >     reached from elsewhere in the subroutine.
> > 
> >     The DW_CFA_GNU_unwind_from_noreturn instruction also creates a new
> >     table row whose location value is the same as this one; this
> >     latter row applies when the given location was reached from
> >     elsewhere in the same subroutine.
> 
> So the effect would be that in the "normal" case we'd continue
> evaluating CFA opcodes as usual until we get to an advance that
> moves past the PC.
> 
> The debugger, on the other hand, would have to know that we are
> unwinding from deeper in the call stack, and set a special flag
> that would stop at the new note?

Yeah, that's the idea.

But I did think of a simpler way to fix this, which wouldn't require
any new Dwarf at all:

Since we're unwinding a frame which will never really be unwound, we
can have that do anything we want.  So, if a function never returns,
why not have the compiler emit CFI that restores the state just
*before* the call insn was executed, not after it returns?  The
unwound PC would point at the call insn itself.  (That's what the user
expects to see anyway.)  The other registers would be as appropriate
before the call was made.  You unwind from there as usual.

I feel like I'm missing something.  Does the compiler have enough info
to do this?  ("No, the compiler doesn't really have enough info to
emit CFI at all, but we do our best, and that's usually okay"?)

It would be weird if you used "return" to artificially pop the frame
and continue.  But that's a bogus thing to do anyway --- the return
address is garbage, so who knows where you're resuming?  If the
function ends with a "call" to 'abort', followed by no more code, then
"return" might just start running at the entry point of the next
function, for goodness' sake.  None of the proposals here will make
that do something sensible, so is this behavior really any more wrong?