From: Andrew Cagney Date: Sat, 22 Apr 2006 23:12:03 +0000 (+0000) Subject: 2006-04-22 Andrew Cagney X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=c5e30d0156ffae49fd287b17d2bdc3f531ae934f;p=binutils-gdb.git 2006-04-22 Andrew Cagney * gdb.texinfo (Contributors): Credit frame unwinder contributors. * gdbint.texinfo (Algorithms): Fix errors in frame documentation. --- diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog index 66ff9d7e6dc..60fe4d05277 100644 --- a/gdb/doc/ChangeLog +++ b/gdb/doc/ChangeLog @@ -1,3 +1,8 @@ +2006-04-22 Andrew Cagney + + * gdb.texinfo (Contributors): Credit frame unwinder contributors. + * gdbint.texinfo (Algorithms): Fix errors in frame documentation. + 2006-04-18 Daniel Jacobowitz * gdbint.texinfo (x86 Watchpoints, Target Conditionals): Update insert diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 790c58dc5b2..a7d182ba843 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -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 diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo index e1d1557a738..7bbd41726ce 100644 --- a/gdb/doc/gdbint.texinfo +++ b/gdb/doc/gdbint.texinfo @@ -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