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

[Andrew Cagney <ac131313@redhat.com>]

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?

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

Andrew