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

[teawater <teawater at gmail dot com>]

Thanks Pedro and Michael,

I think the reason is P record let inferior step recycle in the
linux-nat target.
So when it break by breakpint, it will not let
(pc+gdbarch_decr_pc_after_break (gdbarch)). Then after
adjust_pc_after_break, The PC is error.

I will try to deal with it.

Hui

On Fri, Oct 24, 2008 at 09:50, Pedro Alves <pedro@codesourcery.com> wrote:
> 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
>