summary refs log tree commit diff stats
path: root/results/scraper/launchpad-without-comments/1364501
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:24:58 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:27:06 +0000
commit33606b41d35115f887ea688b1a16f2ff85bf2fe4 (patch)
tree406b2c7b19a087ba437c68f3dbf0b589fa1d6150 /results/scraper/launchpad-without-comments/1364501
parentadedf8771bc4de3113041ca21bd4d0d1c0014b6a (diff)
downloadqemu-analysis-33606b41d35115f887ea688b1a16f2ff85bf2fe4.tar.gz
qemu-analysis-33606b41d35115f887ea688b1a16f2ff85bf2fe4.zip
add launchpad bug reports without comments
Diffstat (limited to 'results/scraper/launchpad-without-comments/1364501')
-rw-r--r--results/scraper/launchpad-without-comments/136450120
1 files changed, 20 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1364501 b/results/scraper/launchpad-without-comments/1364501
new file mode 100644
index 000000000..b12848d8e
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1364501
@@ -0,0 +1,20 @@
+Gdb hangs when trying to single-step after an invalid instruction
+
+When using Gdb to remote-debug a program and manually setting its PC to point to an address containing an invalid instruction, 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
\ No newline at end of file