Re: [reverse RFA] no singlestep-over-BP in reverse

[teawater <teawater@gmail.com>]

Hi guys,

I think we need to decide the behavior of reverse mode breakpoint.

In forward mode, it's clear that CPU stop in address of breakpoint.
The instruction in this address will not be executed.

In reverse mode, If CPU stop in address of breakpoint, I think we have
2 choices:

1. The instruction in this address already reverse executed, it make
program status back to before forward execute this instruction.
Good for it is:
This way make reverse breakpoint same with simple BP.
If program break in reverse mode and got forward execute command. It
don't need special process.
Bad for it is:
This instruction already reverse executed, I think it's not the
original idea of breakpoint. I think the original idea of breakpoint
is stop the program before the instruction forward and reverse
execute.
And for record and replay type reverse target such as inside record
and gdb-freeplay(Sorry I am not very clear), to implement this BP are
not hard. But maybe not easy for others.

2. The instr in this address will not reverse executed, it make
program status in after forward execute this instruction.
Good for it is:
Maybe this is the original idea of breakpoint.
Bad for it is:
If program break in reverse mode and got forward execute command. It
need special process.
Maybe some reverse target can't support it.

Maybe we need support both of them. Target choice what it want, maybe
both of them. And target need to decide if he want a single step to
jump a BP or not.

How do you think about it?


Thanks,
Hui




On Tue, Sep 16, 2008 at 12:21, teawater <teawater@gmail.com> wrote:
> I think maybe some reverse target (in the future?) need it.
> Someone already know it already deal the breakpoint. But the others
> will not know. Maybe I will change inside record to second type.
>
>
> If this single step affect some target, how about let target choice it
> with itself?
>
> Thanks,
> Hui
>
>
>
>
> On Tue, Sep 16, 2008 at 02:31, Michael Snyder <msnyder@vmware.com> wrote:
>> When we're stopped at a breakpoint and we want to
>> continue in reverse, we're not actually going to
>> execute the instruction at the breakpoint -- we're
>> going to de-execute the previous instruction.
>>
>> Therefore there's no need to singlestep before
>> inserting breakpoints.  In fact it would be a bad
>> idea to do so, because if there is a breakpoint at
>> the previous instruction, we WANT to hit it.
>>
>> Note that this patch is to be applied to the reverse branch.
>>
>> 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    15 Sep 2008 18:28:29 -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_FORWARD)
>>        /* 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,
>>
>>
>