Re: Frame handling

[Andrew Cagney <ac131313@redhat.com>]

> Out of interest, what is the theory behind the frame id being made up of
> address + func?

 From the definition of frame ID:

/* The frame object's ID.  This provides a per-frame unique identifier
    that can be used to relocate a `struct frame_info' after a target
    resume or a frame cache destruct.  It of course assumes that the
    inferior hasn't unwound the stack past that frame.  */

struct frame_id
{
   /* The frame's stack address.  This shall be constant through out
      the lifetime of a frame.  Note that this requirement applies to
      not just the function body, but also the prologue and (in theory
      at least) the epilogue.  Since that value needs to fall either on
      the boundary, or within the frame's address range, the frame's
      outer-most address (the inner-most address of the previous frame)
      is used.  Watch out for all the legacy targets that still use the
      function pointer register or stack pointer register.  They are
      wrong.  */
   /* NOTE: cagney/2002-11-16: The ia64 has two stacks and hence two
      frame bases.  This will need to be expanded to accomodate that.  */
   CORE_ADDR stack_addr;
   /* The frame's code address.  This shall be constant through out the
      lifetime of the frame.  While the PC (a.k.a. resume address)
      changes as the function is executed, this code address cannot.
      Typically, it is set to the address of the entry point of the
      frame's function (as returned by frame_func_unwind().  */
   CORE_ADDR code_addr;
};

/* Methods for constructing and comparing Frame IDs.

    NOTE: Given frameless functions A and B, where A calls B (and hence
    B is inner-to A).  The relationships: !eq(A,B); !eq(B,A);
    !inner(A,B); !inner(B,A); all hold.  This is because, while B is
    inner to A, B is not strictly inner to A (being frameless, they
    have the same .base value).  */