This is the mail archive of the gdb-patches@sourceware.org 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: [reverse RFA] no singlestep-over-BP in reverse


Joel Brobecker wrote:
And I believe that consistent behavior / semantics should be:

   If you tell me that you are stopped at instruction 1000,
   regardless of whether you were going forward or backward
   when you got there, then I will expect that if I tell you
   to execute forward, you will execute the instruction at
   1000.

This makes total sense to me. I think I would be very confused by the debugger if I started going back and forth with a debugger that didn't follow the semantics above.

Thanks. By the way I've revised this patch slightly, as shown below. Use "== reverse" instead of "!= forward".

Makes it do the right thing in the "unknown" case.

2008-09-15  Michael Snyder  <msnyder@vmware.com>

	* infrun.c (proceed): No need to singlestep over a breakpoint
	when resuming in reverse.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.300.2.5
diff -u -p -r1.300.2.5 infrun.c
--- infrun.c	5 Sep 2008 03:37:10 -0000	1.300.2.5
+++ infrun.c	17 Sep 2008 00:54:00 -0000
@@ -1226,11 +1226,17 @@ proceed (CORE_ADDR addr, enum target_sig
 
   if (addr == (CORE_ADDR) -1)
     {
-      if (pc == stop_pc && breakpoint_here_p (pc))
+      if (pc == stop_pc && breakpoint_here_p (pc) 
+	  && target_get_execution_direction () != EXEC_REVERSE)
 	/* There is a breakpoint at the address we will resume at,
 	   step one instruction before inserting breakpoints so that
 	   we do not stop right away (and report a second hit at this
-	   breakpoint).  */
+	   breakpoint).
+
+	   Note, we don't do this in reverse, because we won't
+	   actually be executing the breakpoint insn anyway.
+	   We'll be (un-)executing the previous instruction.  */
+
 	oneproc = 1;
       else if (gdbarch_single_step_through_delay_p (gdbarch)
 	       && gdbarch_single_step_through_delay (gdbarch,

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