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] |
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.
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.
(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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |