This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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;
};

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]