Re: [reverse/record] adjust_pc_after_break in reverse execution mode?

[Pedro Alves <pedro at codesourcery dot com>]

A Friday 24 October 2008 00:26:43, Michael Snyder wrote:
> Hi Pedro,
> 
> I duplicated your test case, and found that I could
> reproduce the behavior that you show below, but only
> so long as the branch did not contain your
> "adjust_pc_after_break" patch.
> 
> Once I added that patch to the branch, this behavior
> seemed to go away.
> 
> If I look carefully at what you did below, it seems like
> the forward-replay problem only shows up immediately after
> the reverse-replay problem manifests.  And my experiments
> reflect the same thing.
> 
> The branch is now patched.  Could you spare a moment to
> play with it, and see if you can make it break again?

I've done so a bit this morning, and came to a similar
conclusion, although I noticed Hui's change to set stop_pc in
TARGET_WAITKIND_NO_HISTORY, also also required.  I was wanting
to find time to play a little bit more, but since you're on to it...

I think the issue here, is that when proceeding (continuing) from B1
below,

 B1: PC -->  0x80000001    INSN1
 B2:         0x80000002    INSN2

GDB will always do a single-step to get over B1.  Then, the record
target replays INSN1, and then notices that there's a breakpoint
at 0x80000002.  Remember that GDB told the target to single-step (over
a breakpoint), and to do so, removed all breakpoints from
the inferior.  Hence, the adjust_pc_after_break checks to see if there's
a breakpoint inserted at `0x80000002 - 1', it will find there isn't one
(no breakpoint is inserted while doing the single-step over breakpoints
operation).

In sum, it appears that decr_pc_after_break doesn't matter when you have
continguous breakpoints, as long as you get from from B1's address to B2's
address by single-stepping.  All is good then, it appears!

Without Hui's stop_pc change, when we'd go backwards and hit the
start (end, whatever) of history, we'd get us a wrong stop_pc.  Then,
proceed while doing this check:

     if (pc == stop_pc && breakpoint_here_p (pc) 
	  && execution_direction != EXEC_REVERSE)

pc == stop_pc would fail, and hence the target would not be told
to single-step over the breakpoint, producing the bad effects we were
seeing.  (*)


Hope I'm making sense.  This gave me a bit of a headache
this morning.  :-)

(*) BTW, it seemed that TARGET_WAITKIND_NO_HISTORY overrides the
last event the target would report?  Should'nt the last event in
history be reported normally, and only *on the next* resume we'd
get a TARGET_WAITKIND_NO_HISTORY?  I was wondering if you'd not lose
a possible interesting event, just because it happened to be on
the edge of the history.

> 
> Thanks!
> 
> Pedro Alves wrote:
> > On Sunday 19 October 2008 23:39:20, Michael Snyder wrote:
> >> After codgitating for a bit (that's "thinking" when you're over 50),
> >> I've decided that you're right.
> >>
> >> However, I have a new concern -- I'm worried about what it will do
> >> when it's replaying but going forward.
> >>
> >> Could you possibly revisit your test and see what it does
> >> if you record all the way to line 9 or 10, then back up
> >> to line 6, then continue with breakpoints at 6 and 7?
> > 
> > Eh, you're right.  It's broken.
> > 
> > (gdb) record
> > (gdb) b 6
> > Breakpoint 2 at 0x8048352: file nop.c, line 6.
> > (gdb) b 7
> > Breakpoint 3 at 0x8048353: file nop.c, line 7.
> > (gdb) n
> > 
> > Breakpoint 3, main () at nop.c:7
> > 7               asm ("nop");
> > (gdb) n
> > 8               asm ("nop");
> > (gdb)
> > 9               asm ("nop");
> > (gdb) n
> > 10      }
> > (gdb) rc
> > Continuing.
> > 
> > Breakpoint 3, main () at nop.c:7
> > 7               asm ("nop");
> > (gdb) rn
> > 
> > No more reverse-execution history.
> > main () at nop.c:6
> > 6               asm ("nop");
> > (gdb) n
> > 
> > Breakpoint 2, main () at nop.c:6
> > 6               asm ("nop");
> > (gdb)
> > 8               asm ("nop");
> > (gdb)
> > 9               asm ("nop");
> > (gdb)
> > 
> > 
> > 
> > --
> > Pedro Alves
> 
> 



-- 
Pedro Alves