espressif/binutils-gdb
1
0
Fork 0
mirror of https://github.com/espressif/binutils-gdb.git synced 2025-06-19 00:59:15 +08:00
Code Issues Packages Projects Releases Wiki Activity

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
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> 2006-04-18 Daniel Jacobowitz <dan@codesourcery.com>
* gdbint.texinfo (x86 Watchpoints, Target Conditionals): Update insert * 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 Thorpe, Corinna Vinschen, Ulrich Weigand, and Elena Zannoni, helped
with the migration of old architectures to this new framework. 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 @node Sample Session
@chapter A Sample @value{GDBN} 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. and called functions.
@cindex frame, unwind @cindex frame, unwind
@value{GDBN}'s current frame model is the result of an incremental @value{GDBN}'s frame model, a fresh design, was implemented with the
cleanup of working code, not a fresh design, so it's a little weird. need to support @sc{dwarf}'s Call Frame Information in mind. In fact,
the term ``unwind'' is taken directly from that specification.
The natural model would have a frame object, with methods that read Developers wishing to learn more about unwinders, are encouraged to
and write that frame's registers. Reading or writing the youngest read the the @sc{dwarf} specification.
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.
@findex frame_register_unwind @findex frame_register_unwind
Instead, @value{GDBN}'s model is that you find a frame's registers by @findex get_frame_register
``unwinding'' them from the next younger frame. That is, to access @value{GDBN}'s model is that you find a frame's registers by
the registers of frame #1 (the next-to-youngest frame), you actually ``unwinding'' them from the next younger frame. That is,
apply @code{frame_register_unwind} to frame #0 (the youngest frame). @samp{get_frame_register} which returns the value of a register in
But then the obvious question is: how do you access the registers of frame #1 (the next-to-youngest frame), is implemented by calling frame
the youngest frame itself? How do you ``unwind'' them when they're #0's @code{frame_register_unwind} (the youngest frame). But then the
not wound up? obvious question is: how do you access the registers of the youngest
frame itself?
@cindex sentinel frame @cindex sentinel frame
@findex get_frame_type @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}) == is a sentinel frame, then @code{get_frame_type (@var{f}) ==
SENTINEL_FRAME}. 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 @section Prologue Analysis
@cindex prologue analysis @cindex prologue analysis