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

[teawater <teawater at gmail dot com>]

Thanks Pedro.

I make a patch too.


2008-10-20  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".

Thanks,
Hui

On Mon, Oct 20, 2008 at 20:09, Pedro Alves <pedro@codesourcery.com> wrote:
> A Monday 20 October 2008 01:39:30, Michael Snyder escreveu:
>> Pedro Alves wrote:
>> > On Sunday 19 October 2008 23:39:20, Michael Snyder wrote:
>> >> After codgitating for a bit (that's "thinking" when you're over 50),
>> >> I've decided that you're right.
>> >>
>> >> However, I have a new concern -- I'm worried about what it will do
>> >> when it's replaying but going forward.
>> >>
>> >> Could you possibly revisit your test and see what it does
>> >> if you record all the way to line 9 or 10, then back up
>> >> to line 6, then continue with breakpoints at 6 and 7?
>> >
>> > Eh, you're right.  It's broken.
>>
>> Thought so.
>>
>> See, the problem is that "adjust_pc_after_break" is assuming
>> memory-breakpoint semantics, but Process Record/Replay actually
>> implements hardware-breakpoint semantics.  It watches the
>> instruction-address "bus" and stops when the PC matches the
>> address of a breakpoint.
>>
>> I suspect this is probably a problem with other record/replay
>> back-ends too, but I haven't confirmed it yet.
>>
>> Still, I think that the patch you committed was correct
>> for the reverse case.
>
>> This is a corner case that reveals
>> that "reverse" and "replay" are not synonymous.
>
> They certainly aren't.  When replaying, I believe it's just best to
> behave as close as possible to when it the inferior is really running.
> From the inferior control side, GDB be mostly as agnostic about
> "replay" vs normal run as possibly.
>
> IIUC from reading the code, I see two issues.
>
>  1) When going forward and in reply mode, breakpoint hits are being checked
>    *after* a record item is replays.  IIUC, we should check *before*,
>    and report an adjusted PC.
>
>  2) Un-inserted breakpoints weren't accounted for AFAICT (GDB will
>    un-inserted breakpoints temporarily when stepping over them).
>    Maybe they are, I got lost.  :-)  There's a loop going through the
>    bp_location_chain.  Can you get rid of that and use
>    regular_breakpoint_inserted_here_p or similars?
>
> Below is a 10 minutes hack at it, as a starting point.  Replay stil
> isn't perfect, mainly because I got lost in the record_wait maze --- that,
> needs a bit of clean up.  :-)
>
>>
>> > (gdb) record
>> > (gdb) b 6
>> > Breakpoint 2 at 0x8048352: file nop.c, line 6.
>> > (gdb) b 7
>> > Breakpoint 3 at 0x8048353: file nop.c, line 7.
>> > (gdb) n
>> >
>> > Breakpoint 3, main () at nop.c:7
>> > 7               asm ("nop");
>> > (gdb) n
>> > 8               asm ("nop");
>> > (gdb)
>> > 9               asm ("nop");
>> > (gdb) n
>> > 10      }
>> > (gdb) rc
>> > Continuing.
>> >
>> > Breakpoint 3, main () at nop.c:7
>> > 7               asm ("nop");
>> > (gdb) rn
>> >
>> > No more reverse-execution history.
>> > main () at nop.c:6
>> > 6               asm ("nop");
>> > (gdb) n
>> >
>> > Breakpoint 2, main () at nop.c:6
>> > 6               asm ("nop");
>> > (gdb)
>> > 8               asm ("nop");
>> > (gdb)
>> > 9               asm ("nop");
>> > (gdb)
>> >
>> >
>> >
>> > --
>> > Pedro Alves
>>
>>
>
>
>
> --
> Pedro Alves
>

Attachment: record_wait_breakpoint.txt
Description: Text document