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

[Pedro Alves <pedro at codesourcery dot com>]

On Friday 24 October 2008 01:37:31, Michael Snyder wrote:
> > 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!
> 
> I agree, at least that is the conclusion I am leaning toward.
> 

Not so fast!  I knew I had to spend a little extra thinking about
it, 'cause I knew something was broken, just couldn't find what.  :-)
*as long as you get from from B1's address to B2's address
by single-stepping* was a restriction that doesn't always apply.

Here's a test that will fail in forward record/replay mode, but not
in normal "play" mode.

volatile int global_foo = 0;

int
main (int argc, char **argv)
{
  asm ("nop"); /* 1st insn */
  asm ("nop"); /* 2nd insn */
  asm ("nop"); /* 3rd insn */
  asm ("nop"); /* 4th insn */
  if (!global_foo)
    goto ahead;
  asm ("nop"); /* 5th insn */
  asm ("nop"); /* 6th insn */
  asm ("nop"); /* 7th insn */
  asm ("nop"); /* 8th insn */  <<< break 1 here
 ahead:
  asm ("nop"); /* 9th insn */  <<< break 2 here
 end:
  return 0;
}

If you let the program reply until break 2 is hit, and assuming insn
8th and 9th are assembled as contiguous (they do on x86 -O0 for me), you'll
see that adjust_pc_after_break will indeed make it appear that breakpoint
1 was hit.  Now, nops are nops, but real code could have something
else there...

/me goes back to bed.

-- 
Pedro Alves