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

Pedro Alves
2008-10-23T23:46:31Z

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