qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL for-5.1 3/3] tcg/cpu-exec: precise single-stepping after an in


From: Pavel Dovgalyuk
Subject: Re: [PULL for-5.1 3/3] tcg/cpu-exec: precise single-stepping after an interrupt
Date: Wed, 29 Jul 2020 08:31:25 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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.michel@greensocs.com>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Buglink: https://bugs.launchpad.net/qemu/+bug/757702
Message-Id: <20200717163029.2737546-1-richard.henderson@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]