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

teawater
2008-10-21T07:04:32Z

Sorry I send too much Email. I found that:

if (singlestep_breakpoints_inserted_p
|| !ptid_equal (ecs->ptid, inferior_ptid)
|| !currently_stepping (ecs->event_thread)
|| ecs->event_thread->prev_pc == breakpoint_pc)
regcache_write_pc (regcache, breakpoint_pc);

Before write_pc, there are a lot of thing to check. Do we need to
check it in record_wait?
If so, it actually useless cause it will be set back in adjust_pc_after_break?
Maybe we can let adjust_pc_after_break disable in replay mode.

How do you think?

On Tue, Oct 21, 2008 at 08:21, Pedro Alves <pedro@codesourcery.com> wrote:
> On Tuesday 21 October 2008 00:36:12, teawater wrote:
>> I think your mean is check breakpoint in address
>> read_pc()+gdbarch_decr_pc_after_break (gdbarch) in record_wait, right?
>
> Taking x86 as an example, when you're doing normal debugging and you
> hit a breakpoint (SIGTRAP), the first read_pc GDB does to check where
> what breakpoint was hit, will read back `breakpoint_PC + 1' --- GDB takes care
> getting rid of that `+ 1' offset in infrun.c:adjust_pc_after_break. The
> idea is for you to do the same as the kernel/hardware would --- still
> check for breakpoints at read_pc, but increment PC by 1 before reporting the
> breakpoint to GDB's core. E.g., see the `pc += gdbarch...' line from
> the patch I posted previously, something like:
>
> record.c:record_wait ()
> {
> ...
> + /* Check for breakpoint hits in forward execution. */
> + pc = read_pc ();
> + if (execution_direction == EXEC_FORWARD
> + && regular_breakpoint_inserted_here_p (pc)
> + /* && !single-stepping */)
> + {
> + status->kind = TARGET_WAITKIND_STOPPED;
> + status->value.sig = TARGET_SIGNAL_TRAP;
> + if (software_breakpoint_inserted_here_p (pc))
> + {
> + pc += gdbarch_decr_pc_after_break (gdbarch);
> + write_pc (pc);
> + }
> +
>
> --
> Pedro Alves
>