This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [reverse/record] adjust_pc_after_break in reverse execution mode?
On Saturday 18 October 2008 04:06:29, teawater wrote:
> Great! Please check it in maintree.
Done. I've revised the text a tiny bit, like below.
--
Pedro Alves
2008-10-18 Pedro Alves <pedro@codesourcery.com>
* infrun.c (adjust_pc_after_break): Do nothing if executing in
reverse.
---
gdb/infrun.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c 2008-10-18 00:43:46.000000000 +0100
+++ src/gdb/infrun.c 2008-10-18 04:18:55.000000000 +0100
@@ -1826,6 +1826,35 @@ adjust_pc_after_break (struct execution_
if (ecs->ws.value.sig != TARGET_SIGNAL_TRAP)
return;
+ /* In reverse execution, when a breakpoint is hit, the instruction
+ under it has already been de-executed. The reported PC always
+ points at the breakpoint address, so adjusting it further would
+ be wrong. E.g., consider this case on a decr_pc_after_break == 1
+ architecture:
+
+ B1 0x08000000 : INSN1
+ B2 0x08000001 : INSN2
+ 0x08000002 : INSN3
+ PC -> 0x08000003 : INSN4
+
+ Say you're stopped at 0x08000003 as above. Reverse continuing
+ from that point should hit B2 as below. Reading the PC when the
+ SIGTRAP is reported should read 0x08000001 and INSN2 should have
+ been de-executed already.
+
+ B1 0x08000000 : INSN1
+ B2 PC -> 0x08000001 : INSN2
+ 0x08000002 : INSN3
+ 0x08000003 : INSN4
+
+ We can't apply the same logic as for forward execution, because
+ we would wrongly adjust the PC to 0x08000000, since there's a
+ breakpoint at PC - 1. We'd then report a hit on B1, although
+ INSN1 hadn't been de-executed yet. Doing nothing is the correct
+ behaviour. */
+ if (execution_direction == EXEC_REVERSE)
+ return;
+
/* If this target does not decrement the PC after breakpoints, then
we have nothing to do. */
regcache = get_thread_regcache (ecs->ptid);