[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1364501] Re: Gdb hangs when trying to single-step afte
From: |
Martin |
Subject: |
[Qemu-devel] [Bug 1364501] Re: Gdb hangs when trying to single-step after an invalid instruction |
Date: |
Wed, 03 Sep 2014 14:43:23 -0000 |
Notice there are actually two sides to this problem: not only the
internal exception instruction isn't being processed, but also when we
go back to the cpu_exec loop the syndrome exception won't have any
actual effect since we won't compute the new PC we need in order to jump
to the exception handler. This happens because of this (at cpu-
exec.c:437):
if (unlikely(cpu->singlestep_enabled & SSTEP_NOIRQ)) {
/* Mask out external interrupts for this step. */
interrupt_request &= ~CPU_INTERRUPT_SSTEP_MASK;
}
Because of that, the interrupt request corresponding to our exception
will be ignored and we won't call do_interrupt() as we go on within the
loop. Thus, the PC will remain the same as before because of the very
fact we're single stepping.
I've found a (very ugly) workaround to this bug by commenting out that
line and taking advantage of the fact that env->exception.syndrome isn't
cleansed so that when we try to excecute the syndrome exception
instruction for the 2nd time it'll notice the syndrome value is the same
as before, zero it and procedd without calling cpu_loop_exit().
Right now my question is: do we *really* have to mask out external
interrupts when single-stepping? Even if I found a better way to get the
internal exception to excecute, I'd still have to get past that check in
order to get the correct PC value.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1364501
Title:
Gdb hangs when trying to single-step after an invalid instruction
Status in QEMU:
New
Bug description:
When using Gdb to remote-debug a program and manually setting its PC
to point to an address containing an invalid instruction and then
doing a single step, Qemu will never return control to the remote Gdb.
For instance, let's say address 0x114 contains an invalid instruction.
On the remote Gdb, we'd do:
(gdb) set $pc = 0x114
(gdb) stepi
After doing that we won't get the (gdb) prompt unless we do a Ctrl-C.
If we do so we'll be left at 0x114 instead of going towards the
exception handler as we should. This happens with stepi, step and
next. If instead of single-stepping we used continue, the program will
proceed into the exception handler as it should.
The reason this is happening is that when Qemu realizes it's about to
translate an instruction it doesn't recognize it'll generate a call to
helper_exception_with_syndrome(), which will register the exception
and then call cpu_loop_exit(). At the same time, because we're doing a
single-step, Qemu will also generate a call to
helper_exception_internal() passing it an EXCP_DEBUG, which lets the
system know it'll give control back to the remote debugger, and it
also ends with a call to cpu_loop_exit(). However, because the
syndrome exception calls cpu_loop_exit() first, the call to the
internal exception won't be reached and Qemu will be stuck in a loop
without returning control to the remote debugger.
What makes this a bit tricky to fix is that we must call
cpu_loop_exit() at the end of helper_exception_with_syndrome(),
otherwise the target exception will go undetected and its handler
won't be excecuted.
Tested on latest head by emulating a Stellaris lm3s6965 board and
running RTEMS 4.11:
$ qemu-system-arm -nographic -s -S -M lm3s6965evb -kernel my_rtems_app
Commit hash in qemu.git: 30eaca3acdf17d7bcbd1213eb149c02037edfb0b
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1364501/+subscriptions
[Prev in Thread] |
Current Thread |
[Next in Thread] |