Re: Add frame_is_callee_p(), use in dwarf2-frame.c?

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Jul 02, 2003 at 02:47:11PM -0400, Andrew Cagney wrote:
> Hello,
> 
> Following up the comment:
> 
> >  /* Unwind the PC.
> >
> >     Note that if NEXT_FRAME is never supposed to return (i.e. a call
> >     to abort), the compiler might optimize away the instruction at
> >     NEXT_FRAME's return address.  As a result the return address will
> >     point at some random instruction, and the CFI for that
> >     instruction is probably wortless to us.  GCC's unwinder solves
> >     this problem by substracting 1 from the return address to get an
> >     address in the middle of a presumed call instruction (or the
> >     instruction in the associated delay slot).  This should only be
> >     done for "normal" frames and not for resume-type frames (signal
> >     handlers, sentinel frames, dummy frames).
> >
> >     We don't do what GCC's does here (yet).  It's not clear how
> >     reliable the method is.  There's also a problem with finding the
> >     right FDE; see the comment in dwarf_frame_p.  If dwarf_frame_p
> >     selected this frame unwinder because it found the FDE for the
> >     next function, using the adjusted return address might not yield
> >     a FDE at all.  The problem isn't specific to DWARF CFI; other
> >     unwinders loose in similar ways.  Therefore it's probably
> >     acceptable to leave things slightly broken for now.  */
> >  fs->pc = frame_pc_unwind (next_frame);
> 
> 
> Given MichaelC's flurry of bugs on this, should the fix be added to 6?
> 
> As for the dwarf2_frame_p test, outch!  Any ideas?  Change the parameter 
> to ``address_in_block'', instead of a PC?

That sounds reasonable...

> Regardless, for a ``normal frame'' test, I'd like to suggest 
> ``frame_is_callee_p()'' as something suitable descriptive.  Thoughts?

You've leapt ahead of me again.  What would frame_is_callee_p mean?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer