Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [commit] Move legacy prev->next = ... earlier
@ 2003-04-05 15:56 Andrew Cagney
  2003-04-05 18:21 ` Andrew Cagney
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cagney @ 2003-04-05 15:56 UTC (permalink / raw)
  To: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

Hello,

The function:

	get_frame_pc(fi)
		=== fi->pc

is about to be changed to:

	get_frame_pc(fi)
		=== fi->next->prev_pc.value;

but that doesn't work very well when fi->next isn't initialized.

The attached modifies legacy_get_prev_frame() so that it initializes 
prev->next var earlier in the frame's creation and thus ensuring that 
get_frame_pc() can still work.

The new frame code doesn't suffer from this problem.

committed,
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 5830 bytes --]

2003-04-05  Andrew Cagney  <cagney@redhat.com>

	* frame.c (get_frame_id): Update comment.
	(legacy_get_prev_frame): Update comment.
	* gdbarch.sh: Delete check for EXTRA_FRAME_INFO.
	* gdbarch.h: Regenerate.
	* config/sparc/tm-sparc.h (EXTRA_FRAME_INFO): Delete.
	* frame.h: Delete #ifdef EXTRA_FRAME_INFO code.

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.96
diff -u -r1.96 frame.c
--- frame.c	5 Apr 2003 03:55:59 -0000	1.96
+++ frame.c	5 Apr 2003 15:37:43 -0000
@@ -65,9 +65,7 @@
       fi->unwind->this_id (fi->next, &fi->prologue_cache, &fi->id);
       fi->id_p = 1;
       /* FIXME: cagney/2002-12-18: Instead of this hack, should only
-	 store the frame ID in PREV_FRAME.  Unfortunatly, some
-	 architectures (HP/UX) still reply on EXTRA_FRAME_INFO and,
-	 hence, still poke at the "struct frame_info" object directly.  */
+	 store the frame ID in PREV_FRAME.  */
       fi->frame = fi->id.base;
     }
   return frame_id_build (fi->frame, get_frame_pc (fi));
@@ -1150,9 +1148,7 @@
 	 frame base, in the frame object.  */
 
       /* FIXME: cagney/2002-12-18: Instead of this hack, should only
-	 store the frame ID in PREV_FRAME.  Unfortunatly, some
-	 architectures (HP/UX) still reply on EXTRA_FRAME_INFO and,
-	 hence, still poke at the "struct frame_info" object directly.  */
+	 store the frame ID in PREV_FRAME.  */
       /* FIXME: cagney/2003-04-04: Once ->frame is eliminated, this
          assignment can go.  */
       prev->frame = prev->id.base;
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.81
diff -u -r1.81 frame.h
--- frame.h	5 Apr 2003 03:56:00 -0000	1.81
+++ frame.h	5 Apr 2003 15:37:44 -0000
@@ -320,7 +320,7 @@
 
 /* Describe the saved registers of a frame.  */
 
-#if defined (EXTRA_FRAME_INFO) || defined (FRAME_FIND_SAVED_REGS)
+#if defined (FRAME_FIND_SAVED_REGS)
 /* XXXX - deprecated */
 struct frame_saved_regs
   {
@@ -387,13 +387,6 @@
     /* Allocated by frame_saved_regs_zalloc () which is called /
        initialized by DEPRECATED_FRAME_INIT_SAVED_REGS(). */
     CORE_ADDR *saved_regs;	/*NUM_REGS + NUM_PSEUDO_REGS*/
-
-#ifdef EXTRA_FRAME_INFO
-    /* XXXX - deprecated */
-    /* Anything extra for this structure that may have been defined
-       in the machine dependent files. */
-      EXTRA_FRAME_INFO
-#endif
 
     /* Anything extra for this structure that may have been defined
        in the machine dependent files. */
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.219
diff -u -r1.219 gdbarch.sh
--- gdbarch.sh	1 Apr 2003 17:17:27 -0000	1.219
+++ gdbarch.sh	5 Apr 2003 15:37:46 -0000
@@ -821,12 +821,6 @@
    converted. */
 
 #if GDB_MULTI_ARCH
-#if defined (EXTRA_FRAME_INFO)
-#error "EXTRA_FRAME_INFO: replaced by struct frame_extra_info"
-#endif
-#endif
-
-#if GDB_MULTI_ARCH
 #if defined (FRAME_FIND_SAVED_REGS)
 #error "FRAME_FIND_SAVED_REGS: replaced by DEPRECATED_FRAME_INIT_SAVED_REGS"
 #endif
Index: config/sparc/tm-sparc.h
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/tm-sparc.h,v
retrieving revision 1.43
diff -u -r1.43 tm-sparc.h
--- config/sparc/tm-sparc.h	26 Mar 2003 22:39:53 -0000	1.43
+++ config/sparc/tm-sparc.h	5 Apr 2003 15:37:46 -0000
@@ -406,53 +406,6 @@
 /* DEPRECATED_FRAME_CHAIN takes a frame's nominal address and produces
    the frame's chain-pointer. */
 
-/* In the case of the Sun 4, the frame-chain's nominal address
-   is held in the frame pointer register.
-
-   On the Sun4, the frame (in %fp) is %sp for the previous frame.
-   From the previous frame's %sp, we can find the previous frame's
-   %fp: it is in the save area just above the previous frame's %sp.
-
-   If we are setting up an arbitrary frame, we'll need to know where
-   it ends.  Hence the following.  This part of the frame cache
-   structure should be checked before it is assumed that this frame's
-   bottom is in the stack pointer.
-
-   If there isn't a frame below this one, the bottom of this frame is
-   in the stack pointer.
-
-   If there is a frame below this one, and the frame pointers are
-   identical, it's a leaf frame and the bottoms are the same also.
-
-   Otherwise the bottom of this frame is the top of the next frame.
-
-   The bottom field is misnamed, since it might imply that memory from
-   bottom to frame contains this frame.  That need not be true if
-   stack frames are allocated in different segments (e.g. some on a
-   stack, some on a heap in the data segment).
-
-   GCC 2.6 and later can generate ``flat register window'' code that
-   makes frames by explicitly saving those registers that need to be
-   saved.  %i7 is used as the frame pointer, and the frame is laid out
-   so that flat and non-flat calls can be intermixed freely within a
-   program.  Unfortunately for GDB, this means it must detect and
-   record the flatness of frames.
-
-   Since the prologue in a flat frame also tells us where fp and pc
-   have been stashed (the frame is of variable size, so their location
-   is not fixed), it's convenient to record them in the frame info.  */
-
-#define EXTRA_FRAME_INFO \
-  CORE_ADDR bottom;      \
-  int in_prologue;       \
-  int flat;              \
-  /* Following fields only relevant for flat frames.  */ \
-  CORE_ADDR pc_addr;     \
-  CORE_ADDR fp_addr;     \
-  /* Add this to ->frame to get the value of the stack pointer at the */ \
-  /* time of the register saves.  */ \
-  int sp_offset;
-
 /* We need to override DEPRECATED_GET_SAVED_REGISTER so that we can
    deal with the way outs change into ins in different frames.  */
 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [commit] Move legacy prev->next = ... earlier
  2003-04-05 15:56 [commit] Move legacy prev->next = ... earlier Andrew Cagney
@ 2003-04-05 18:21 ` Andrew Cagney
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 2003-04-05 18:21 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb-patches

[-- Attachment #1: Type: text/plain, Size: 72 bytes --]

Did I mention that it wasn't my day.  Again, the real patch :-/

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 2217 bytes --]

2003-04-05  Andrew Cagney  <cagney@redhat.com>

	* frame.c (legacy_get_prev_frame): Link prev to next at the
	function start.  Update comments.

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.97
diff -u -r1.97 frame.c
--- frame.c	5 Apr 2003 15:39:33 -0000	1.97
+++ frame.c	5 Apr 2003 15:42:22 -0000
@@ -1029,10 +1029,7 @@
   struct frame_info *prev;
   int fromleaf;
 
-  /* Allocate the new frame but do not wire it in to the frame chain.
-     Some (bad) code in INIT_FRAME_EXTRA_INFO tries to look along
-     frame->next to pull some fancy tricks (of course such code is, by
-     definition, recursive).  Try to prevent it.
+  /* Allocate the new frame.
 
      There is no reason to worry about memory leaks, should the
      remainder of the function fail.  The allocated memory will be
@@ -1042,6 +1039,17 @@
   prev = FRAME_OBSTACK_ZALLOC (struct frame_info);
   prev->level = this_frame->level + 1;
 
+  /* Do not completly wire it in to the frame chain.  Some (bad) code
+     in INIT_FRAME_EXTRA_INFO tries to look along frame->prev to pull
+     some fancy tricks (of course such code is, by definition,
+     recursive).
+  
+     On the other hand, methods, such as get_frame_pc() and
+     get_frame_base() rely on being able to walk along the frame
+     chain.  Make certain that at least they work by providing that
+     link.  Of course things manipulating prev can't go back.  */
+  prev->next = this_frame;
+
   /* NOTE: cagney/2002-11-18: Should have been correctly setting the
      frame's type here, before anything else, and not last, at the
      bottom of this function.  The various
@@ -1155,7 +1163,6 @@
 
       /* Link it in.  */
       this_frame->prev = prev;
-      prev->next = this_frame;
 
       /* FIXME: cagney/2002-01-19: This call will go away.  Instead of
 	 initializing extra info, all frames will use the frame_cache
@@ -1230,7 +1237,6 @@
 
   /* Link in the already allocated prev frame.  */
   this_frame->prev = prev;
-  prev->next = this_frame;
   deprecated_update_frame_base_hack (prev, address);
 
   /* This change should not be needed, FIXME!  We should determine

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-04-05 18:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-05 15:56 [commit] Move legacy prev->next = ... earlier Andrew Cagney
2003-04-05 18:21 ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox