A frame is a construct that gdb uses to keep track of calling and called functions.
gdb's frame model, a fresh design, was implemented with the need to support dwarf's Call Frame Information in mind. In fact, the term “unwind” is taken directly from that specification. Developers wishing to learn more about unwinders, are encouraged to read the dwarf specification, available from http://www.dwarfstd.org.
gdb's model is that you find a frame's registers by
“unwinding” them from the next younger frame. That is,
‘get_frame_register’ which returns the value of a register in
frame #1 (the next-to-youngest frame), is implemented by calling frame
frame_register_unwind (the youngest frame). But then the
obvious question is: how do you access the registers of the youngest
To answer this question, gdb has the sentinel frame, the
“-1st” frame. Unwinding registers from the sentinel frame gives you
the current values of the youngest real frame's registers. If f
is a sentinel frame, then
The architecture registers a list of frame unwinders (
frame_unwind), using the functions
frame_unwind_append_unwinder. Each unwinder includes a
sniffer. Whenever gdb needs to unwind a frame (to fetch the
previous frame's registers or the current frame's ID), it calls
registered sniffers in order to find one which recognizes the frame.
The first time a sniffer returns non-zero, the corresponding unwinder
is assigned to the frame.
Every frame has an associated ID, of type
The ID includes the stack base and function start address for
the frame. The ID persists through the entire life of the frame,
including while other called frames are running; it is used to
locate an appropriate
struct frame_info from the cache.
Every time the inferior stops, and at various other times, the frame
cache is flushed. Because of this, parts of gdb which need
to keep track of individual frames cannot use pointers to
frame_info. A frame ID provides a stable reference to a frame, even
when the unwinder must be run again to generate a new
frame_info for the same frame.
The frame's unwinder's
this_id method is called to find the ID.
Note that this is different from register unwinding, where the next
prev_register is called to unwind this frame's
Both stack base and function address are required to identify the frame, because a recursive function has the same function address for two consecutive frames and a leaf function may have the same stack address as its caller. On some platforms, a third address is part of the ID to further disambiguate frames—for instance, on IA-64 the separate register stack address is included in the ID.
An invalid frame ID (
outer_frame_id) returned from the
this_id method means to stop unwinding after this frame.
null_frame_id is another invalid frame ID which should be used
when there is no frame. For instance, certain breakpoints are attached
to a specific frame, and that frame is identified through its frame ID
(we use this to implement the "finish" command). Using
null_frame_id as the frame ID for a given breakpoint means
that the breakpoint is not specific to any frame. The
method should never return
Each unwinder includes a
prev_register method. This method
takes a frame, an associated cache pointer, and a register number.
It returns a
struct value * describing the requested register,
as saved by this frame. This is the value of the register that is
current in this frame's caller.
The returned value must have the same type as the register. It may have any lvalue type. In most circumstances one of these routines will generate the appropriate value:
frame_unwind_got_constant, except that the value is a target address. This is frequently used for the stack pointer, which is not explicitly saved but has a known offset from this frame's stack pointer. For architectures with a flat unified address space, this is generally the same as