On 17.07.2020 21:16, Richard Henderson wrote:
When single-stepping with a debugger attached to QEMU, and when an
interrupt is raised, the debugger misses the first instruction after
the interrupt.
Tested-by: Luc Michel <luc.mic...@greensocs.com>
Reviewed-by: Luc Michel <luc.mic...@greensocs.com>
Buglink: https://bugs.launchpad.net/qemu/+bug/757702
Message-Id: <20200717163029.2737546-1-richard.hender...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
---
accel/tcg/cpu-exec.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 6a3d3a3cfc..66d38f9d85 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -588,7 +588,13 @@ static inline bool cpu_handle_interrupt(CPUState *cpu,
else {
if (cc->cpu_exec_interrupt(cpu, interrupt_request)) {
replay_interrupt();
- cpu->exception_index = -1;
+ /*
+ * After processing the interrupt, ensure an EXCP_DEBUG is
+ * raised when single-stepping so that GDB doesn't miss the
+ * next instruction.
+ */
+ cpu->exception_index =
+ (cpu->singlestep_enabled ? EXCP_DEBUG : -1);
*last_tb = NULL;
I just rebased my reverse debugging patches and noticed that this breaks
the debugging in record/replay icount mode for i386.
At some points "si" in remote gdb does nothing.
This happens because of CPU_INTERRUPT_POLL. These are not real
interrupts and converted into HW interrupt_request flags later.
Therefore we shouldn't stop when there is CPU_INTERRUPT_POLL request.
}
/* The target hook may have updated the 'cpu->interrupt_request';
Pavel Dovgalyuk
