[patch/rfc] Delete legacy code from infrun.c

[Andrew Cagney <cagney at gnu dot org>]

Hello,

This removes all the legacy_frame_p calls in infrun.c.

In theory, since the old/new frame code is compatible, this should have 
no effect.

In reality, I've nothing to test this on -- all the architectures I play 
with use the new frame code!

Thoughts?  I'll give this a few days.
Andrew

2004-03-31  Andrew Cagney  <cagney@redhat.com>
 
	* infrun.c (handle_step_into_function): Delete code conditional on
	legacy_frame_p.
	(handle_inferior_event, step_over_function): Ditto.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.143
diff -u -r1.143 infrun.c
--- infrun.c	31 Mar 2004 19:40:28 -0000	1.143
+++ infrun.c	31 Mar 2004 22:58:54 -0000
@@ -1263,25 +1263,6 @@
   if (step_over_calls == STEP_OVER_ALL || IGNORE_HELPER_CALL (stop_pc))
     {
       /* We're doing a "next".  */
-
-      if (legacy_frame_p (current_gdbarch)
-	  && pc_in_sigtramp (stop_pc)
-          && frame_id_inner (step_frame_id,
-                             frame_id_build (read_sp (), 0)))
-	/* NOTE: cagney/2004-03-15: This is only needed for legacy
-	   systems.  On non-legacy systems step_over_function doesn't
-	   use STEP_FRAME_ID and hence the below update "hack" isn't
-	   needed.  */
-        /* We stepped out of a signal handler, and into its calling
-           trampoline.  This is misdetected as a subroutine call, but
-           stepping over the signal trampoline isn't such a bad idea.
-           In order to do that, we have to ignore the value in
-           step_frame_id, since that doesn't represent the frame
-           that'll reach when we return from the signal trampoline.
-           Otherwise we'll probably continue to the end of the
-           program.  */
-        step_frame_id = null_frame_id;
-
       step_over_function (ecs);
       keep_going (ecs);
       return;
@@ -2523,16 +2504,8 @@
 
   /* Did we just step into a singal trampoline (either by stepping out
      of a handler, or by taking a signal)?  */
-  /* NOTE: cagney/2004-03-16: Replaced (except for legacy) a check for
-     "pc_in_sigtramp(stop_pc) != pc_in_sigtramp(step_pc)" with
-     frame_type == SIGTRAMP && !frame_id_eq.  The latter is far more
-     robust as it will correctly handle nested signal trampolines.  */
-  if (legacy_frame_p (current_gdbarch)
-      ? (pc_in_sigtramp (stop_pc)
-	 && !pc_in_sigtramp (prev_pc)
-	 && INNER_THAN (read_sp (), step_sp))
-      : (get_frame_type (get_current_frame ()) == SIGTRAMP_FRAME
-	 && !frame_id_eq (get_frame_id (get_current_frame ()), step_frame_id)))
+  if (get_frame_type (get_current_frame ()) == SIGTRAMP_FRAME
+      && !frame_id_eq (get_frame_id (get_current_frame ()), step_frame_id))
     {
       {
 	struct frame_id current_frame = get_frame_id (get_current_frame ());
@@ -2924,42 +2897,16 @@
 
   check_for_old_step_resume_breakpoint ();
 
-  /* NOTE: cagney/2004-03-15: Code using the current value of
-     "step_frame_id", instead of unwinding that frame ID, removed (at
-     least for non-legacy platforms).  On s390 GNU/Linux, after taking
-     a signal, the program is directly resumed at the signal handler
-     and, consequently, the PC would point at at the first instruction
-     of that signal handler but STEP_FRAME_ID would [incorrectly] at
-     the interrupted code when it should point at the signal
-     trampoline.  By always and locally doing a frame ID unwind, it's
-     possible to assert that the code is always using the correct
-     ID.  */
-  if (legacy_frame_p (current_gdbarch))
-    {
-      if (frame_id_p (step_frame_id)
-	  && !IN_SOLIB_DYNSYM_RESOLVE_CODE (sr_sal.pc))
-	/* NOTE: cagney/2004-02-27: Use the global state's idea of the
-	   stepping frame ID.  I suspect this is done as it is lighter
-	   weight than a call to get_prev_frame.  */
-	/* NOTE: cagney/2004-03-15: See comment above about how this
-	   is also broken.  */
-	sr_id = step_frame_id;
-      else
-	/* NOTE: cagney/2004-03-15: This is the way it was 'cos this
-	   is the way it always was.  It should be using the unwound
-	   (or caller's) ID, and not this (or the callee's) ID.  It
-	   appeared to work because: legacy architectures used the
-	   wrong end of the frame for the ID.stack (inner-most rather
-	   than outer-most) so that the callee's id.stack (un
-	   adjusted) matched the caller's id.stack giving the
-	   "correct" id; more often than not
-	   !IN_SOLIB_DYNSYM_RESOLVE_CODE and hence the code above (it
-	   was originally later in the function) fixed the ID by using
-	   global state.  */
-	sr_id = get_frame_id (get_current_frame ());
-    }
-  else
-    sr_id = frame_unwind_id (get_current_frame ());
+  /* NOTE: cagney/2004-03-31: Code using the current value of
+     "step_frame_id", instead of unwinding that frame ID, removed.  On
+     s390 GNU/Linux, after taking a signal, the program is directly
+     resumed at the signal handler and, consequently, the PC would
+     point at at the first instruction of that signal handler but
+     STEP_FRAME_ID would [incorrectly] at the interrupted code when it
+     should point at the signal trampoline.  By always and locally
+     doing a frame ID unwind, it's possible to assert that the code is
+     always using the correct ID.  */
+  sr_id = frame_unwind_id (get_current_frame ());
 
   step_resume_breakpoint = set_momentary_breakpoint (sr_sal, sr_id, bp_step_resume);