qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] target-i386: guest variable shift by 0 provokes shift by -1


From: Peter Maydell
Subject: [Qemu-devel] target-i386: guest variable shift by 0 provokes shift by -1
Date: Tue, 18 Mar 2014 12:33:26 +0000

If you run 'make check' under clang's -fsanitize=undefined, then
(among other things) the acpi test provokes these warnings:

/home/petmay01/linaro/qemu-from-laptop/qemu/tcg/optimize.c:833:44:
runtime error: shift exponent 18446744073709551615 is too large for
64-bit type 'tcg_target_ulong' (aka 'unsigned long')
/home/petmay01/linaro/qemu-from-laptop/qemu/tcg/optimize.c:226:28:
runtime error: shift exponent 18446744073709551615 is too large for
64-bit type 'uint64_t' (aka 'unsigned long')

(18446744073709551615 is -1 as an unsigned decimal.)

This turns out to be caused by this guest code:

0x0000000007fe9a56:  xor    %ebp,%ebp
0x0000000007fe9a58:  mov    $0x1,%eax
0x0000000007fe9a5d:  mov    %ebp,%ecx
0x0000000007fe9a5f:  shl    %cl,%eax

which we turn into these TCG ops:

 ---- 0x7fe9a56
 72  discard cc_dst
 73  movi_i64 tmp0,$0x0
 74  ext32u_i64 rbp,tmp0
 75
 ---- 0x7fe9a58
 76  movi_i64 tmp0,$0x1
 77  ext32u_i64 rax,tmp0
 78
 ---- 0x7fe9a5d
 79  mov_i64 tmp0,rbp
 80  ext32u_i64 rcx,tmp0
 81
 ---- 0x7fe9a5f
 82  mov_i64 tmp1,rcx
 83  mov_i64 tmp0,rax
 84  movi_i64 tmp13,$0x1f
 85  and_i64 tmp1,tmp1,tmp13
 86  movi_i64 tmp13,$0x1
 87  sub_i64 tmp3,tmp1,tmp13
 88  shl_i64 tmp3,tmp0,tmp3
 89  shl_i64 tmp0,tmp0,tmp1
 90  ext32u_i64 rax,tmp0
 91  movi_i64 tmp13,$0x0
 92  mov_i64 cc_dst,tmp0
 93  mov_i64 cc_src,tmp3
 94  movi_i32 tmp5,$0x24
 95  movi_i32 tmp6,$0x31
 96  movi_i32 tmp11,$0x0
 97  mov_i32 tmp12,tmp1
 98  movcond_i32 cc_op,tmp12,tmp11,tmp5,tmp6,ne

In this case the constant propagation code is smart
enough to figure out that tmp1 is always zero at op 85,
and therefore tmp3 is -1 at op 87. It then tries to use
the shift constant of -1 in C when looking at op 88, and
clang complains about the C undefined behaviour.

This seems to be the result of the code in gen_shift_rm_T1(),
which (unlike gen_shift_rm_im()) doesn't special case a zero
shift count, and so will generate TCG that has undefined
behaviour if the shift count is zero.

RTH: it looks like you touched this code last, so
at this point I decided that rather than figure out
what exactly the x86 shift semantics are and what
this code was doing I'd just report it and let you
look at it :-)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]