FreeChainXenon/binutils-gdb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

2006-04-22 Andrew Cagney <cagney@redhat.com>

Browse source 
* gdb.texinfo (Contributors): Credit frame unwinder contributors.
	* gdbint.texinfo (Algorithms): Fix errors in frame documentation.
This commit is contained in:
Andrew Cagney 2006-04-22 23:12:03 +00:00
parent 9aa8aaf750
commit c5e30d0156
3 changed files with 31 additions and 43 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
gdb/doc/ChangeLog
View file

@ -1,3 +1,8 @@
2006-04-22 Andrew Cagney <cagney@redhat.com>
* gdb.texinfo (Contributors): Credit frame unwinder contributors.
* gdbint.texinfo (Algorithms): Fix errors in frame documentation.
2006-04-18 Daniel Jacobowitz <dan@codesourcery.com>
* gdbint.texinfo (x86 Watchpoints, Target Conditionals): Update insert

13
gdb/doc/gdb.texinfo
View file

@ -484,6 +484,19 @@ Sakamoto, Yoshinori Sato, Michael Snyder, Andreas Schwab, Jason
Thorpe, Corinna Vinschen, Ulrich Weigand, and Elena Zannoni, helped
with the migration of old architectures to this new framework.
Andrew Cagney completely re-designed and re-implemented @value{GDBN}'s
unwinder framework, this consisting of a fresh new design featuring
frame IDs, independent frame sniffers, and the sentinel frame. Mark
Kettenis implemented the @sc{dwarf 2} unwinder, Jeff Johnston the
libunwind unwinder, and Andrew Cagney the dummy, sentinel, tramp, and
trad unwinders. The architecture specific changes, each involving a
complete rewrite of the architecture's frame code, were carried out by
Jim Blandy, Joel Brobecker, Kevin Buettner, Andrew Cagney, Stephane
Carrez, Randolph Chung, Orjan Friberg, Richard Henderson, Daniel
Jacobowitz, Jeff Johnston, Mark Kettenis, Theodore A. Roth, Kei
Sakamoto, Yoshinori Sato, Michael Snyder, Corinna Vinschen, and Ulrich
Weigand.
@node Sample Session
@chapter A Sample @value{GDBN} Session

56
gdb/doc/gdbint.texinfo
View file

@ -232,25 +232,21 @@ A frame is a construct that @value{GDBN} uses to keep track of calling
and called functions.
@cindex frame, unwind
@value{GDBN}'s current frame model is the result of an incremental
cleanup of working code, not a fresh design, so it's a little weird.
The natural model would have a frame object, with methods that read
and write that frame's registers. Reading or writing the youngest
frame's registers would simply read or write the processor's current
registers, since the youngest frame is running directly on the
processor. Older frames might have some registers saved on the stack
by younger frames, so accessing the older frames' registers would do a
mix of memory accesses and register accesses, as appropriate.
@value{GDBN}'s frame model, a fresh design, was implemented with the
need to support @sc{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 the @sc{dwarf} specification.
@findex frame_register_unwind
Instead, @value{GDBN}'s model is that you find a frame's registers by
``unwinding'' them from the next younger frame. That is, to access
the registers of frame #1 (the next-to-youngest frame), you actually
apply @code{frame_register_unwind} to frame #0 (the youngest frame).
But then the obvious question is: how do you access the registers of
the youngest frame itself? How do you ``unwind'' them when they're
not wound up?
@findex get_frame_register
@value{GDBN}'s model is that you find a frame's registers by
``unwinding'' them from the next younger frame. That is,
@samp{get_frame_register} which returns the value of a register in
frame #1 (the next-to-youngest frame), is implemented by calling frame
#0's @code{frame_register_unwind} (the youngest frame). But then the
obvious question is: how do you access the registers of the youngest
frame itself?
@cindex sentinel frame
@findex get_frame_type
@ -261,32 +257,6 @@ the current values of the youngest real frame's registers. If @var{f}
is a sentinel frame, then @code{get_frame_type (@var{f}) ==
SENTINEL_FRAME}.
@findex create_new_frame
@vindex FRAME_FP
@code{FRAME_FP} in the machine description has no meaning to the
machine-independent part of @value{GDBN}, except that it is used when
setting up a new frame from scratch, as follows:
@smallexample
create_new_frame (read_register (DEPRECATED_FP_REGNUM), read_pc ()));
@end smallexample
@cindex frame pointer register
Other than that, all the meaning imparted to @code{DEPRECATED_FP_REGNUM}
is imparted by the machine-dependent code. So,
@code{DEPRECATED_FP_REGNUM} can have any value that is convenient for
the code that creates new frames. (@code{create_new_frame} calls
@code{DEPRECATED_INIT_EXTRA_FRAME_INFO} if it is defined; that is where
you should use the @code{DEPRECATED_FP_REGNUM} value, if your frames are
nonstandard.)
@cindex frame chain
Given a @value{GDBN} frame, define @code{DEPRECATED_FRAME_CHAIN} to
determine the address of the calling function's frame. This will be
used to create a new @value{GDBN} frame struct, and then
@code{DEPRECATED_INIT_EXTRA_FRAME_INFO} and
@code{DEPRECATED_INIT_FRAME_PC} will be called for the new frame.
@section Prologue Analysis
@cindex prologue analysis