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

[teawater <teawater at gmail dot com>]

On Tue, Sep 16, 2008 at 23:03, teawater <teawater@gmail.com> wrote:
> 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.

If we want support both of them. Maybe we can support a command make
user can get the type and set the type(Maybe some target just support
1 tyoe).


>
> 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,
>>>
>>>
>>
>