lock user-mode and semantic-bugs

1 files changed, 22 insertions, 0 deletions

diff --git a/results/classifier/user-mode-bugs/2483 b/results/classifier/user-mode-bugs/2483
new file mode 100644
index 000000000..9919ec444
--- /dev/null
+++ b/results/classifier/user-mode-bugs/2483
@@ -0,0 +1,22 @@
+
+
+m68k: jsr (sp) doesn't work as expected
+Description of problem:
+Consider the following code (disassembly from ghidra). This copies the current `SP` to `A1` then copies 0x68 bytes from the address pointed at by `A0` to the address pointed at by `A1` with increment. This should end up with a copy of some bytes and `SP` pointing at the first.
+
+```
+        ff8241e6 22 4f           movea.l    SP,A1
+        ff8241e8 70 68           moveq      #0x68,D0
+                             LAB_ff8241ea                                    XREF[1]:     ff8241ee(j)  
+        ff8241ea 12 d8           move.b     (A0)+,(A1)+
+        ff8241ec 53 80           subq.l     #0x1,D0
+        ff8241ee 66 fa           bne.b      LAB_ff8241ea
+        ff8241f0 4e 97           jsr        (SP)
+```
+
+`SP` is `0x3bfc` at the `jsr` so we'd expect to jump to `0x3bfc` and put the address to return to at `0x3bf8` so the `jsr` can return I think?
+What currently happens in QEMU is the return address is put at `0xb3f8` and `PC` also becomes `0x3bf8` and the return address starts being executed as code and things go off the rails.
+
+Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the `PC` is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing.
+
+![image](/uploads/d5fd6f455e5a433735d8fae2be3d53ee/image.png){width=289 height=759}