blob: 7c0fba74ff682979a5c5b39e5d7216941f6d14a2 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
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.
{width=289 height=759}
|