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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
graphic: 0.975
permissions: 0.966
debug: 0.964
architecture: 0.963
assembly: 0.959
device: 0.954
PID: 0.954
performance: 0.952
register: 0.951
virtual: 0.949
semantic: 0.949
arm: 0.947
kernel: 0.946
files: 0.943
boot: 0.934
socket: 0.929
x86: 0.912
TCG: 0.909
network: 0.906
hypervisor: 0.901
ppc: 0.900
risc-v: 0.897
i386: 0.891
peripherals: 0.888
vnc: 0.879
VMM: 0.869
user-level: 0.845
mistranslation: 0.833
KVM: 0.820
x86: BT/BTS/BTR/BTC: ZF flag is unaffected
Hello!
Bug was found in qemu.git.
See target-i386/translate.c:
case 0x1ba: /* bt/bts/btr/btc Gv, im */
ot = dflag + OT_WORD;
modrm = ldub_code(s->pc++);
op = (modrm >> 3) & 7;
mod = (modrm >> 6) & 3;
rm = (modrm & 7) | REX_B(s);
if (mod != 3) {
s->rip_offset = 1;
gen_lea_modrm(s, modrm, ®_addr, &offset_addr);
gen_op_ld_T0_A0(ot + s->mem_index);
} else {
gen_op_mov_TN_reg(ot, 0, rm);
}
/* load shift */
val = ldub_code(s->pc++);
gen_op_movl_T1_im(val);
if (op < 4)
goto illegal_op;
op -= 4;
goto bt_op;
case 0x1a3: /* bt Gv, Ev */
op = 0;
goto do_btx;
case 0x1ab: /* bts */
op = 1;
goto do_btx;
case 0x1b3: /* btr */
op = 2;
goto do_btx;
case 0x1bb: /* btc */
op = 3;
do_btx:
ot = dflag + OT_WORD;
modrm = ldub_code(s->pc++);
reg = ((modrm >> 3) & 7) | rex_r;
mod = (modrm >> 6) & 3;
rm = (modrm & 7) | REX_B(s);
gen_op_mov_TN_reg(OT_LONG, 1, reg);
if (mod != 3) {
gen_lea_modrm(s, modrm, ®_addr, &offset_addr);
/* specific case: we need to add a displacement */
gen_exts(ot, cpu_T[1]);
tcg_gen_sari_tl(cpu_tmp0, cpu_T[1], 3 + ot);
tcg_gen_shli_tl(cpu_tmp0, cpu_tmp0, ot);
tcg_gen_add_tl(cpu_A0, cpu_A0, cpu_tmp0);
gen_op_ld_T0_A0(ot + s->mem_index);
} else {
gen_op_mov_TN_reg(ot, 0, rm);
}
bt_op:
tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 << (3 + ot)) - 1);
switch(op) {
case 0:
tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]);
tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf
break;
case 1:
tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
tcg_gen_movi_tl(cpu_tmp0, 1);
tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
tcg_gen_or_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
case 2:
tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
tcg_gen_movi_tl(cpu_tmp0, 1);
tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
tcg_gen_not_tl(cpu_tmp0, cpu_tmp0);
tcg_gen_and_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
default:
case 3:
tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]);
tcg_gen_movi_tl(cpu_tmp0, 1);
tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]);
tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0);
break;
}
s->cc_op = CC_OP_SARB + ot;
if (op != 0) {
if (mod != 3)
gen_op_st_T0_A0(ot + s->mem_index);
else
gen_op_mov_reg_T0(ot, rm);
tcg_gen_mov_tl(cpu_cc_src, cpu_tmp4);
tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf
}
break;
always set zf...
There is fixed patch.
It would be helpful if you could submit patches in line with the guidance documented on the wiki:
http://wiki.qemu.org/Contribute/SubmitAPatch
In particular, patches should be sent to the mailing list in the right format, and we cannot apply any patch without a signed-off-by line.
Thanks.
On 12/14/2011 06:08 PM, malc wrote:
> On Wed, 14 Dec 2011, Daniil Troshkov wrote:
>
> > Public bug reported:
> >
> > Hello!
> >
> > Bug was found in qemu.git.
> > See target-i386/translate.c:
> >
>
> [..snip..]
>
> Intel's documentation doesn't cover this, AMD's says that ZF is undefined, so,
> question is: why do you think QEMU is wrong here?
The Intel documentation states that ZF is unaffected.
--
error compiling committee.c: too many arguments to function
On 12/14/2011 06:22 PM, malc wrote:
> On Wed, 14 Dec 2011, Avi Kivity wrote:
>
> > On 12/14/2011 06:08 PM, malc wrote:
> > > On Wed, 14 Dec 2011, Daniil Troshkov wrote:
> > >
> > > > Public bug reported:
> > > >
> > > > Hello!
> > > >
> > > > Bug was found in qemu.git.
> > > > See target-i386/translate.c:
> > > >
> > >
> > > [..snip..]
> > >
> > > Intel's documentation doesn't cover this, AMD's says that ZF is undefined, so,
> > > question is: why do you think QEMU is wrong here?
> >
> > The Intel documentation states that ZF is unaffected.
> >
>
> Right, i was blind, anyways, AMD disagrees.
>
Best to be conservative here.
--
error compiling committee.c: too many arguments to function
>Best to be conservative here.
What is it means?
On 12/14/2011 06:33 PM, malc wrote:
> >
> > Best to be conservative here.
> >
>
> Point being, any code that relies on it being in any particular state is
> broken (potentially, on AMD chips)
Yes of course, but not all software is written to be portable. Probably
the only thing that will break here is a vendor test suite, but even so,
if we can comply to the spec, we should.
--
error compiling committee.c: too many arguments to function
Looking at the previous comments ... is there anything left to do here? Or can we close this bug nowadays?
[Expired for QEMU because there has been no activity for 60 days.]
|