* [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