This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Frame unwinder methods
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 07 Mar 2003 09:41:23 -0500
- Subject: Frame unwinder methods
Just FYI,
Attached is the current list of methods that are needed when
re-implementing a `traditional' or `prologue based' frame unwinder.
It's down to two (from four) which must be a good thing :-)
Andrew
/* The following unwind functions all assume a frame chain like:
(outer) prev <-> this <-> next (inner); Even though some unwind to
THIS frame (frame ID) and others unwind the PREV frame, they are
all, consistently passed NEXT frame and THIS cache.
The intent is to clarify the relationship between NEXT frame and
THIS cache. It is, of course, at the expense of confusing somewhat
the expected unwind behavior of PC/REG unwind VS ID unwind. Sigh. */
/* Assuming the frame chain: (outer) prev <-> this <-> next (inner);
use the NEXT frame, and its register unwind method, to determine
the frame ID of THIS frame.
A frame ID provides an invariant that can be used to re-identify an
instance of a frame. It is a combination of the frame's `base' and
the frame's function's code.
Traditionally, THIS frame's ID was determined by examining THIS
frame's function's prologue and identifying which register/offset
are being used as THIS frame's base.
THIS_CACHE can be used to share any prolog analysis data with the
other unwind methods. Memory for that cache should be allocated
using frame_obstack_zalloc(). */
typedef void (frame_unwind_id_ftype) (struct frame_info *next_frame,
void **this_cache,
struct frame_id *this_id);
/* Assuming the frame chain: (outer) prev <-> this <-> next (inner);
use the NEXT frame, and its register unwind method, to unwind THIS
frame's registers, returning the value of REGNUM in PREV frame.
Traditionally, THIS frame's registers were unwound by examining
THIS frame's function's prologue and identifying which registers
that prolog code saved on the stack.
Ex: Assuming THIS is a frameless function that has saved the return
address (to PREV) in R1, then: a request to unwind THIS's PC
(returning the value of PC in PREV), becomes a request for the
value of R1 in THIS (that is where the value was saved), which
becomes a request to unwind R1 from NEXT.
THIS_CACHE can be used to share any prologue analysis data with the
other unwind methods. Memory for that cache should be allocated
using frame_obstack_zalloc(). */
typedef void (frame_unwind_reg_ftype) (struct frame_info *next_frame,
void **this_cache,
int prev_regnum,
int *optimized,
enum lval_type * lvalp,
CORE_ADDR *addrp,
int *realnump, void *valuep);
struct frame_unwind
{
/* Should the frame's type go here? */
/* Should an attribute indicating the frame's address-in-block go
here? */
frame_unwind_id_ftype *id;
frame_unwind_reg_ftype *reg;
};