This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: STEP_SKIPS_DELAY question, sort of


Orjan Friberg wrote:


Gah. Please ignore the previous patch (and sorry); what I posted only works when doing a continue when stopped at the branch instruction. Doing a step (which leaves us in the delay slot) followed by another step (or continue for that matter) prematurely inserts the breakpoint.


Ok, second try (still concept patch though): the change in proceed is needed for when we resume from the delay slot - in that case we need to single-step again before re-inserting the breakpoint (similar to the MIPS case). The change in handle_inferior_event (and I'll happily agree it's far more questionable) is needed for when we resume at the branch instruction itself. Comments?

Can this new mechanism somehow superseed STEP_SKIPS_DELAY - it seems to be the exact oposite but there could be common ground here.


Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.156
diff -u -p -r1.156 infrun.c
--- infrun.c    11 May 2004 23:30:31 -0000      1.156
+++ infrun.c    7 Jun 2004 12:59:10 -0000
@@ -748,6 +748,14 @@ proceed (CORE_ADDR addr, enum target_sig
          && breakpoint_here_p (read_pc () + 4)
          && STEP_SKIPS_DELAY (read_pc ()))
        oneproc = 1;
+
+      /* If we stepped into a delay slot, and the preceding instruction
+        will be re-executed when resuming, step again before re-inserting
+        the breakpoint.  */
+      if (STEP_SKIPS_IN_DELAY_P
+         && "
+         && STEP_SKIPS_IN_DELAY (read_pc ()))
+       oneproc = 1;
     }
   else
     {

They both seem to be asking the question: "given PC and a list of breakpoints, should the inferior be h/w single-stepped?". That would mean pushing the alternative:
breakpoint_here_p (read_pc () - 2)
breakpoint_here_p (read_pc () + 4)
calls into that architecture method.


@@ -1975,7 +1983,17 @@ handle_inferior_event (struct execution_
       /* Don't even think about breakpoints if just proceeded over a
          breakpoint.  */
       if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected)
-       bpstat_clear (&stop_bpstat);
+       {
+         bpstat_clear (&stop_bpstat);
+
+         /* If we stepped into a delay slot, and the preceding instruction
+            will be re-executed when resuming, step again before re-inserting
+            the breakpoint.  */
+         if (STEP_SKIPS_IN_DELAY_P
+             && breakpoint_here_p (read_pc () - 2)
+             && STEP_SKIPS_IN_DELAY (read_pc ()))
+           ecs->another_trap = 1;
+       }
       else
        {
          /* See if there is a breakpoint at the current PC.  */


I'm just not sure how this bit of logic should fit in. I'm guessing its the second half of the state m/c sequence:


1. step off breakpoint at `PC'
2. step through delay

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]