blob: 4296edeb2cae097bde9a5dbcc913a195772f51b6 (
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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
performance: 0.919
graphic: 0.916
device: 0.801
debug: 0.775
peripherals: 0.760
architecture: 0.722
assembly: 0.714
network: 0.704
files: 0.627
arm: 0.626
PID: 0.602
ppc: 0.600
vnc: 0.586
socket: 0.572
semantic: 0.544
permissions: 0.542
hypervisor: 0.511
i386: 0.510
kernel: 0.476
boot: 0.442
user-level: 0.410
register: 0.395
mistranslation: 0.349
risc-v: 0.320
x86: 0.268
virtual: 0.250
VMM: 0.229
TCG: 0.129
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.
{width=289 height=759}
|
