blob: 8c2407deb6ad5bbeac99496f7b0d8e8c95cddcba (
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
risc-v: 0.818
VMM: 0.774
permissions: 0.773
device: 0.749
kernel: 0.742
ppc: 0.737
arm: 0.732
socket: 0.723
network: 0.718
peripherals: 0.697
architecture: 0.692
performance: 0.686
debug: 0.679
semantic: 0.669
PID: 0.644
mistranslation: 0.627
TCG: 0.625
assembly: 0.609
graphic: 0.593
register: 0.581
files: 0.550
virtual: 0.524
hypervisor: 0.522
KVM: 0.491
x86: 0.463
vnc: 0.440
boot: 0.432
user-level: 0.402
i386: 0.278
m68k: 68030 (?): fmove.p doesn't work (6888[1|2] emulation isn't implemented??)
Description of problem:
The following code should be executing a move to the fpu and then a move from it and then branching.
```
ff813590 f2 10 4f 00 fmove.p (A0),FP6
ff813594 f2 11 6f 7f fmove.p FP6,(A1) {#0x7f}
ff813598 61 00 fe 52 bsr.w SUB_ff8133ec
```
However, hitting the instruction at `0xff813590` causes the `PC` to go off into the weeds and then the emulation gets stuck and never proceeds.
Before executing the instruction the CPU state looks like this
```
(qemu) info registers
CPU#0
D0 = ffffffff A0 = ff813584 F0 = c004 cc00000000000000 ( -51)
D1 = 0000ffff A1 = 0000335e F1 = c00d a866000000000000 ( -21555)
D2 = 00000002 A2 = ff8138a2 F2 = 401b 91a2b3c000000000 ( 3.0542e+08)
D3 = 00000003 A3 = ff824008 F3 = 3fb4 ab3c4d0000000000 ( 3.54107e-23)
D4 = 00000004 A4 = ff81dbb6 F4 = 3d12 919a22ab33bc4000 (3.84141e-226)
D5 = 00000000 A5 = 00000400 F5 = 1020 8060708090a0b0c0 ( 0)
D6 = 0000000c A6 = 00003790 F6 = 7fff ffffffffffffffff ( nan)
D7 = 00000000 A7 = 0000316e F7 = 7fff ffffffffffffffff ( nan)
PC = ff813590 SR = 2708 T:0 I:7 SI -N---
FPSR = 00000000 ----
FPCR = 0000 X RN
A7(MSP) = 00000000 A7(USP) = 80000000 ->A7(ISP) = 00003796
VBR = 0x0000338e
SFC = 3 DFC 0
SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
MMUSR 00000000, fault at 00000000
```
After single stepping:
```
(qemu) info registers
CPU#0
D0 = ffffffff A0 = ff813584 F0 = c004 cc00000000000000 ( -51)
D1 = 0000ffff A1 = 0000335e F1 = c00d a866000000000000 ( -21555)
D2 = 00000002 A2 = ff8138a2 F2 = 401b 91a2b3c000000000 ( 3.0542e+08)
D3 = 00000003 A3 = ff824008 F3 = 3fb4 ab3c4d0000000000 ( 3.54107e-23)
D4 = 00000004 A4 = ff81dbb6 F4 = 3d12 919a22ab33bc4000 (3.84141e-226)
D5 = 00000000 A5 = 00000400 F5 = 1020 8060708090a0b0c0 ( 0)
D6 = 0000000c A6 = 00003790 F6 = 7fff ffffffffffffffff ( nan)
D7 = 00000000 A7 = 00003166 F7 = 7fff ffffffffffffffff ( nan)
PC = ff8138a2 SR = 2708 T:0 I:7 SI -N---
FPSR = 00000000 ----
FPCR = 0000 X RN
A7(MSP) = 00000000 A7(USP) = 80000000 ->A7(ISP) = 0000316e
VBR = 0x0000338e
SFC = 3 DFC 0
SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
MMUSR 00000000, fault at 00000000
```
With this code the `VBR` doesn't point at an actual vector table from what I can tell and it is pointing at some memory that contains `0xff8138a2` so I guess it hits the instruction, the FPU isn't implemented so it tries to do an `F-line exception` instead but the vector table doesn't actually contain a handler and it's trying to execute garbage that causes the lock up.
Basically, I guess I need to implement the 6888[1|2] for this code to work.
|