This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: dwarf-frame.c question
- From: Jim Blandy <jimb at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Andrew Cagney <ac131313 at redhat dot com>, Mark Kettenis <kettenis at chello dot nl>, mludvig at suse dot cz, gdb at sources dot redhat dot com, Alexandre Oliva <aoliva at redhat dot com>
- Date: 03 Jun 2003 01:30:56 -0500
- Subject: Re: dwarf-frame.c question
- References: <3ED381CB.5050207@suse.cz><200305291544.h4TFi7aL031832@elgar.kettenis.dyndns.org><3ED66564.1020506@redhat.com><200305292222.h4TMMmGm000694@elgar.kettenis.dyndns.org><3ED693F5.9040108@redhat.com> <vt2ptm09nz9.fsf@zenia.red-bean.com><3ED7BFD1.7060902@redhat.com> <vt2y90kowlv.fsf@zenia.red-bean.com><20030603054552.GD19075@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?