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

Michael Snyder
2008-09-17T18:18:24Z

Committed to branch.

teawater wrote:
> Looks good. Please check it in.
>
> And I think we have decided the how to deal with breakpoint.
>
> On Wed, Sep 17, 2008 at 08:54, Michael Snyder <msnyder@vmware.com> wrote:
>> Joel Brobecker wrote:
>>>> And I believe that consistent behavior / semantics should be:
>>>>
>>>> If you tell me that you are stopped at instruction 1000,
>>>> regardless of whether you were going forward or backward
>>>> when you got there, then I will expect that if I tell you
>>>> to execute forward, you will execute the instruction at
>>>> 1000.
>>> This makes total sense to me. I think I would be very confused
>>> by the debugger if I started going back and forth with a debugger
>>> that didn't follow the semantics above.
>> Thanks. By the way I've revised this patch slightly,
>> as shown below. Use "== reverse" instead of "!= forward".
>>
>> Makes it do the right thing in the "unknown" case.
>>
>>
>> 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 17 Sep 2008 00:54:00 -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_REVERSE)
>> /* 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,
>>
>>