* Re: REGISTER_IN_WINDOW_P
[not found] ` <3CC5F9DB.70203@cygnus.com>
@ 2002-04-23 23:30 ` David S. Miller
2002-04-24 6:43 ` REGISTER_IN_WINDOW_P Andrew Cagney
0 siblings, 1 reply; 3+ messages in thread
From: David S. Miller @ 2002-04-23 23:30 UTC (permalink / raw)
To: ac131313; +Cc: gdb, gdb-patches
From: Andrew Cagney <ac131313@cygnus.com>
Date: Tue, 23 Apr 2002 20:18:35 -0400
> It is only referenced or set by the i960 target specific code, would
> it be ok to remove references to it from the GDB internals
> documentation?
...
you might as well, at the same time, replace the macro by a static
function.
Done, how does this look?
2002-04-23 David S. Miller <davem@redhat.com>
* i960-tdep.c (register_in_window_p): New function.
(i960_find_saved_register): Use it instead of
REGISTER_IN_WINDOW_P.
* config/i960/tm-i960.h (REGISTER_IN_WINDOW): Kill.
2002-04-23 David S. Miller <davem@redhat.com>
* gdbint.texinfo (REGISTER_IN_WINDOW): Delete definition.
--- ./config/i960/tm-i960.h.~1~ Sun Apr 21 08:52:34 2002
+++ ./config/i960/tm-i960.h Tue Apr 23 23:25:09 2002
@@ -127,21 +127,6 @@ extern void i960_get_saved_register (cha
i960_get_saved_register(raw_buffer, optimized, addrp, frame, regnum, lval)
-
-/* Is this register part of the register window system? A yes answer
- implies that 1) The name of this register will not be the same in
- other frames, and 2) This register is automatically "saved" upon
- subroutine calls and thus there is no need to search more than one
- stack frame for it.
-
- On the i960, in fact, the name of this register in another frame is
- "mud" -- there is no overlap between the windows. Each window is
- simply saved into the stack (true for our purposes, after having been
- flushed; normally they reside on-chip and are restored from on-chip
- without ever going to memory). */
-
-#define REGISTER_IN_WINDOW_P(regnum) ((regnum) <= R15_REGNUM)
-
/* Number of bytes of storage in the actual machine representation
for register N. On the i960, all regs are 4 bytes except for floating
point, which are 10. NINDY only sends us 8 byte values for these,
--- ./doc/gdbint.texinfo.~1~ Sun Apr 21 18:39:54 2002
+++ ./doc/gdbint.texinfo Tue Apr 23 23:23:39 2002
@@ -3044,11 +3044,6 @@ pointer. It examines the current state
Define this if you need to supply your own definition for the function
@code{get_saved_register}.
-@item REGISTER_IN_WINDOW_P (@var{regnum})
-@findex REGISTER_IN_WINDOW_P
-Define this to be an expression that is 1 if the given register is in
-the window.
-
@item IBM6000_TARGET
@findex IBM6000_TARGET
Shows that we are configured for an IBM RS/6000 target. This
--- ./i960-tdep.c.~1~ Sun Apr 21 08:19:06 2002
+++ ./i960-tdep.c Tue Apr 23 23:25:00 2002
@@ -122,6 +122,24 @@ check_host (void)
}
}
\f
+/* Is this register part of the register window system? A yes answer
+ implies that 1) The name of this register will not be the same in
+ other frames, and 2) This register is automatically "saved" upon
+ subroutine calls and thus there is no need to search more than one
+ stack frame for it.
+
+ On the i960, in fact, the name of this register in another frame is
+ "mud" -- there is no overlap between the windows. Each window is
+ simply saved into the stack (true for our purposes, after having been
+ flushed; normally they reside on-chip and are restored from on-chip
+ without ever going to memory). */
+
+static int
+register_in_window_p (int regnum)
+{
+ return regnum <= R15_REGNUM;
+}
+
/* i960_find_saved_register ()
Return the address in which frame FRAME's value of register REGNUM
@@ -154,7 +172,7 @@ i960_find_saved_register (struct frame_i
stack pointer saved for *this* frame; this is returned from the
next frame. */
- if (REGISTER_IN_WINDOW_P (regnum))
+ if (register_in_window_p (regnum))
{
frame1 = get_next_frame (frame);
if (!frame1)
^ permalink raw reply [flat|nested] 3+ messages in thread