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
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
mistranslation: 0.833
other: 0.724
semantic: 0.674
graphic: 0.655
instruction: 0.640
device: 0.639
assembly: 0.607
KVM: 0.579
vnc: 0.552
boot: 0.518
socket: 0.508
network: 0.409
sparc32plus (and others?) has x86 code generation errors on 64bit hosts
On 64bit hosts, the load and store functions compile improperly. The issue is the call to gen_address_mask() under the ld and st functions in target-sparc/translate.c. Below are some snips from the log file. Doing a gdb debug, this results in constant access violation errors which I do not see when debugging qemu in powerpc mode.
--------------
IN:
0x0000000040804aa8: st %i0, [ %fp + 0x44 ]
OP:
---- 0x40804aa8
ld_i64 tmp1,regwptr,$0xb0
mov_i64 tmp0,tmp1
movi_i64 tmp2,$0x44
add_i64 tmp0,tmp0,tmp2
ld_i64 tmp2,regwptr,$0x80
ext32u_i64 tmp0,tmp0
qemu_st32 tmp2,tmp0,$0x0
OUT: [size=345]
0x6032d7f0: mov 0x40(%r14),%rbp
0x6032d7f4: mov 0xb0(%rbp),%rbx
0x6032d7fb: add $0x44,%rbx
0x6032d7ff: mov 0x80(%rbp),%rbp
0x6032d806: mov %ebx,%ebx <- bug
0x6032d808: mov %ebp,%edi
0x6032d80a: bswap %edi
0x6032d80c: mov %edi,(%rbx)
--------------
IN:
0x0000000040804aec: add %l7, %o7, %l7
0x0000000040804af0: ld [ %l7 ], %g2
OP:
---- 0x40804aec
ld_i64 tmp1,regwptr,$0x78
ld_i64 tmp2,regwptr,$0x38
add_i64 tmp0,tmp1,tmp2
st_i64 tmp0,regwptr,$0x78
---- 0x40804af0
ld_i64 tmp1,regwptr,$0x78
mov_i64 tmp0,tmp1
ext32u_i64 tmp0,tmp0
qemu_ld32u g2,tmp0,$0x0
OUT: [size=395]
0x6032da80: mov 0x40(%r14),%rbp
0x6032da84: mov 0x78(%rbp),%rbx
0x6032da88: mov 0x38(%rbp),%r12
0x6032da8c: add %r12,%rbx
0x6032da8f: mov %rbx,0x78(%rbp)
0x6032da93: mov 0x78(%rbp),%rbx
0x6032da97: mov %ebx,%ebx <- bug
0x6032da99: mov (%rbx),%ebx
In 64bit mode, doing a 32bit operation will result in the top 32bit's being zero'd. I attempted to simply disable the call to gen_address_mask() but that did not fix the issue and actually caused the sparc32plus I was testing to become unusable.
I forgot to add, this is on the latest master branch as of this post. I am doing a static compile with debug enabled. My test is doing a chroot of a sparc system built from debootstrap.
Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays?
I no longer have a setup to test this so I can only say to close it.
On Jul 11, 2017 4:15 PM, "Thomas Huth" <email address hidden> wrote:
> Can you still reproduce this problem wit the latest release of QEMU
> (currently version 2.9.0), or could we close this bug nowadays?
>
> ** Changed in: qemu
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1095531
>
> Title:
> sparc32plus (and others?) has x86 code generation errors on 64bit
> hosts
>
> Status in QEMU:
> Incomplete
>
> Bug description:
> On 64bit hosts, the load and store functions compile improperly. The
> issue is the call to gen_address_mask() under the ld and st functions
> in target-sparc/translate.c. Below are some snips from the log file.
> Doing a gdb debug, this results in constant access violation errors
> which I do not see when debugging qemu in powerpc mode.
>
> --------------
> IN:
> 0x0000000040804aa8: st %i0, [ %fp + 0x44 ]
>
> OP:
> ---- 0x40804aa8
> ld_i64 tmp1,regwptr,$0xb0
> mov_i64 tmp0,tmp1
> movi_i64 tmp2,$0x44
> add_i64 tmp0,tmp0,tmp2
> ld_i64 tmp2,regwptr,$0x80
> ext32u_i64 tmp0,tmp0
> qemu_st32 tmp2,tmp0,$0x0
>
> OUT: [size=345]
> 0x6032d7f0: mov 0x40(%r14),%rbp
> 0x6032d7f4: mov 0xb0(%rbp),%rbx
> 0x6032d7fb: add $0x44,%rbx
> 0x6032d7ff: mov 0x80(%rbp),%rbp
> 0x6032d806: mov %ebx,%ebx <- bug
> 0x6032d808: mov %ebp,%edi
> 0x6032d80a: bswap %edi
> 0x6032d80c: mov %edi,(%rbx)
>
> --------------
> IN:
> 0x0000000040804aec: add %l7, %o7, %l7
> 0x0000000040804af0: ld [ %l7 ], %g2
>
> OP:
> ---- 0x40804aec
> ld_i64 tmp1,regwptr,$0x78
> ld_i64 tmp2,regwptr,$0x38
> add_i64 tmp0,tmp1,tmp2
> st_i64 tmp0,regwptr,$0x78
>
> ---- 0x40804af0
> ld_i64 tmp1,regwptr,$0x78
> mov_i64 tmp0,tmp1
> ext32u_i64 tmp0,tmp0
> qemu_ld32u g2,tmp0,$0x0
>
> OUT: [size=395]
> 0x6032da80: mov 0x40(%r14),%rbp
> 0x6032da84: mov 0x78(%rbp),%rbx
> 0x6032da88: mov 0x38(%rbp),%r12
> 0x6032da8c: add %r12,%rbx
> 0x6032da8f: mov %rbx,0x78(%rbp)
> 0x6032da93: mov 0x78(%rbp),%rbx
> 0x6032da97: mov %ebx,%ebx <- bug
> 0x6032da99: mov (%rbx),%ebx
>
> In 64bit mode, doing a 32bit operation will result in the top 32bit's
> being zero'd. I attempted to simply disable the call to
> gen_address_mask() but that did not fix the issue and actually caused
> the sparc32plus I was testing to become unusable.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1095531/+subscriptions
>
[Expired for QEMU because there has been no activity for 60 days.]
|