This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]