[PATCH]: Convert another macro into a functions for Linux/x86

[Mark Kettenis <kettenis at wins dot uva dot nl>]

No regressions.  Checked in.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* i386-linux-tdep.c (FRAMELESS_SIGNAL): Moved here from
	config/i386/nm-linux.h (including comment).
	(i386_linux_frame_chain): New function implementing guts of the
	former FRAME_CHAIN macro, but using read_memory_unsigned_integer
	instead of read_memory_integer.
	(i386_linux_frame_saved_pc): Removed doc pointing to
	i386/tm-linux.h for an explanation of FRAMELESS_SIGNAL since that
	now lives in this file.
	* config/i386/tm-linux.h (FRAMELESS_SIGNAL): Moved to
	i386-linux-tdep.c (including comment).
	(FRAME_CHAIN): Redefined in terms of i386_linux_frame_chain.
	(i386_linux_frame_chain): New prototype.

Index: i386-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-linux-tdep.c,v
retrieving revision 1.6
diff -u -p -r1.6 i386-linux-tdep.c
--- i386-linux-tdep.c 2001/03/26 19:51:47 1.6
+++ i386-linux-tdep.c 2001/03/28 11:35:02
@@ -277,6 +277,44 @@ i386_linux_sigtramp_saved_sp (struct fra
   return read_memory_integer (addr + LINUX_SIGCONTEXT_SP_OFFSET, 4);
 }
 
+/* Signal trampolines don't have a meaningful frame.  As in
+   "i386/tm-i386.h", the frame pointer value we use is actually the
+   frame pointer of the calling frame -- that is, the frame which was
+   in progress when the signal trampoline was entered.  GDB mostly
+   treats this frame pointer value as a magic cookie.  We detect the
+   case of a signal trampoline by looking at the SIGNAL_HANDLER_CALLER
+   field, which is set based on IN_SIGTRAMP.
+
+   When a signal trampoline is invoked from a frameless function, we
+   essentially have two frameless functions in a row.  In this case,
+   we use the same magic cookie for three frames in a row.  We detect
+   this case by seeing whether the next frame has
+   SIGNAL_HANDLER_CALLER set, and, if it does, checking whether the
+   current frame is actually frameless.  In this case, we need to get
+   the PC by looking at the SP register value stored in the signal
+   context.
+
+   This should work in most cases except in horrible situations where
+   a signal occurs just as we enter a function but before the frame
+   has been set up.  */
+
+#define FRAMELESS_SIGNAL(frame)					\
+  ((frame)->next != NULL					\
+   && (frame)->next->signal_handler_caller			\
+   && frameless_look_for_prologue (frame))
+
+CORE_ADDR
+i386_linux_frame_chain (struct frame_info *frame)
+{
+  if (frame->signal_handler_caller || FRAMELESS_SIGNAL (frame))
+    return frame->frame;
+
+  if (! inside_entry_file (frame->pc))
+    return read_memory_unsigned_integer (frame->frame, 4);
+
+  return 0;
+}
+
 /* Return the saved program counter for FRAME.  */
 
 CORE_ADDR
@@ -285,11 +323,6 @@ i386_linux_frame_saved_pc (struct frame_
   if (frame->signal_handler_caller)
     return i386_linux_sigtramp_saved_pc (frame);
 
-  /* See comment in "i386/tm-linux.h" for an explanation what this
-     "FRAMELESS_SIGNAL" stuff is supposed to do.
-
-     FIXME: kettenis/2001-03-26: That comment should eventually be
-     moved to this file.  */
   if (FRAMELESS_SIGNAL (frame))
     {
       CORE_ADDR sp = i386_linux_sigtramp_saved_sp (frame->next);
@@ -309,7 +342,6 @@ i386_linux_saved_pc_after_call (struct f
 
   return read_memory_integer (read_register (SP_REGNUM), 4);
 }
-
 
 
 /* Calling functions in shared libraries.  */
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.12
diff -u -p -r1.12 tm-linux.h
--- config/i386/tm-linux.h 2001/03/26 19:51:47 1.12
+++ config/i386/tm-linux.h 2001/03/28 11:35:02
@@ -46,41 +46,9 @@ extern struct link_map_offsets *i386_lin
 #define IN_SIGTRAMP(pc, name) i386_linux_in_sigtramp (pc, name)
 extern int i386_linux_in_sigtramp (CORE_ADDR, char *);
 
-/* Signal trampolines don't have a meaningful frame.  As in tm-i386.h,
-   the frame pointer value we use is actually the frame pointer of the
-   calling frame--that is, the frame which was in progress when the
-   signal trampoline was entered.  gdb mostly treats this frame
-   pointer value as a magic cookie.  We detect the case of a signal
-   trampoline by looking at the SIGNAL_HANDLER_CALLER field, which is
-   set based on IN_SIGTRAMP.
-
-   When a signal trampoline is invoked from a frameless function, we
-   essentially have two frameless functions in a row.  In this case,
-   we use the same magic cookie for three frames in a row.  We detect
-   this case by seeing whether the next frame has
-   SIGNAL_HANDLER_CALLER set, and, if it does, checking whether the
-   current frame is actually frameless.  In this case, we need to get
-   the PC by looking at the SP register value stored in the signal
-   context.
-
-   This should work in most cases except in horrible situations where
-   a signal occurs just as we enter a function but before the frame
-   has been set up.  */
-
-#define FRAMELESS_SIGNAL(FRAME)					\
-  ((FRAME)->next != NULL					\
-   && (FRAME)->next->signal_handler_caller			\
-   && frameless_look_for_prologue (FRAME))
-
 #undef FRAME_CHAIN
-#define FRAME_CHAIN(FRAME)					\
-  ((FRAME)->signal_handler_caller				\
-   ? (FRAME)->frame						\
-    : (FRAMELESS_SIGNAL (FRAME)					\
-       ? (FRAME)->frame						\
-       : (!inside_entry_file ((FRAME)->pc)			\
-	  ? read_memory_integer ((FRAME)->frame, 4)		\
-	  : 0)))
+#define FRAME_CHAIN(frame) i386_linux_frame_chain (frame)
+extern CORE_ADDR i386_linux_frame_chain (struct frame_info *frame);
 
 #undef FRAME_SAVED_PC
 #define FRAME_SAVED_PC(frame) i386_linux_frame_saved_pc (frame)