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

[teawater <teawater at gmail dot com>]

I see.
I make a patch for it.

2008-10-21  Hui Zhu  <teawater@gmail.com>

	* record.c (record_wait): Check breakpint before forward
	execute in replay mode.
	Check breakpoint use function "breakpoint_inserted_here_p"
	in replay mode.
	Set pc if forward execute, gdbarch_decr_pc_after_break is not
	0 and this is not single step in replay mode.

Thanks,
Hui


On Wed, Oct 22, 2008 at 02:30, Michael Snyder <msnyder@vmware.com> wrote:
> teawater wrote:
>>
>> 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?
>
> I think we should leave adjust_pc_after_break alone,
> and change record_wait so that it adjusts the pc by
> adding decr_pc_after_break(gdbarch) when appropriate.
>
> Whenever possible, gdb should not need to know the difference
> between replay and live debugging.  This keeps things simple,
> and preserves modularity.
>
> Of course, you don't have access to the "ecs" object, which
> is local to infrun.  But you do know whether or not gdb is
> stepping.  And (for now) you know that there is only one
> thread, so you can (for now) ignore the thread id (ptid).
>
> The value of "step" that was passed to record_resume
> came from "currently_stepping", so you should be able
> to use that.
>
> Something close to the patch that Pedro posted should work...
>
>
>
>

Attachment: record_wait_breakpoint.txt
Description: Text document