add new classifier result

1 files changed, 33 insertions, 0 deletions

diff --git a/results/classifier/105/graphic/2483 b/results/classifier/105/graphic/2483
new file mode 100644
index 000000000..bcfde5060
--- /dev/null
+++ b/results/classifier/105/graphic/2483
@@ -0,0 +1,33 @@
+graphic: 0.916
+device: 0.801
+assembly: 0.714
+network: 0.704
+instruction: 0.688
+vnc: 0.586
+socket: 0.572
+semantic: 0.544
+other: 0.475
+boot: 0.442
+mistranslation: 0.349
+KVM: 0.006
+
+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}