Re: Frame handling

Andrew Cagney
2003-07-01T13:02:05Z

> 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). */