From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJmqD-0001dG-2Z for qemu-devel@nongnu.org; Fri, 06 Feb 2015 12:37:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJmq8-0006Cx-Po for qemu-devel@nongnu.org; Fri, 06 Feb 2015 12:37:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJmq8-0006BW-DJ for qemu-devel@nongnu.org; Fri, 06 Feb 2015 12:37:12 -0500 Message-ID: <54D4FBC3.1050501@redhat.com> Date: Fri, 06 Feb 2015 10:37:07 -0700 From: Eric Blake MIME-Version: 1.0 References: <1423233250-15853-1-git-send-email-peter.maydell@linaro.org> In-Reply-To: <1423233250-15853-1-git-send-email-peter.maydell@linaro.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XkkDKBDACDJxkDKN3OGGBwIFfQMrK48Um" Subject: Re: [Qemu-devel] [PATCH 0/4] target-arm: fix various clang UB sanitizer warnings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , qemu-devel@nongnu.org Cc: patches@linaro.org, Richard Henderson This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XkkDKBDACDJxkDKN3OGGBwIFfQMrK48Um Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/06/2015 07:34 AM, Peter Maydell wrote: > This patchset fixes a collection of warnings emitted by the clang > undefined behaviour sanitizer in the course of booting an AArch64 > Linux guest to a shell prompt. These are all various kinds of bad > shift (shifting into the sign bit, left shifting negative values, > shifting by more than the size of the data type). >=20 > There remains one set of warnings which I'm not sure how to > approach. We have an enum for the valid syndrome register EC > field values: >=20 > enum arm_exception_class { > EC_UNCATEGORIZED =3D 0x00, > [...] > EC_VECTORCATCH =3D 0x3a, > EC_AA64_BKPT =3D 0x3c, > }; >=20 > The EC field is a 6 bit field at the top of the 32 bit syndrome > register, so we define >=20 > #define ARM_EL_EC_SHIFT 26 >=20 > and have utility functions that assemble syndrome values like: >=20 > static inline uint32_t syn_aa64_bkpt(uint32_t imm16) > { > return (EC_AA64_BKPT << ARM_EL_EC_SHIFT) | ARM_EL_IL | (imm16 & 0xf= fff); > } >=20 > Unfortunately this is UB, because C says that enums can be > signed types, and if the enum is signed then "EC_AA64_BKPT << 26" > is shifting into the sign bit of a signed type. >=20 > I can't see any nice way of avoiding this. Possible nasty ways: >=20 > (1) Drop the enum and just use old-fashioned > #define EC_AA64_BKPT 0x3cU > since then we can force them to be unsigned > (2) Cast the constant to unsigned at point of use > (3) Keep the enum and add defines wrapping actual use > #define EC_AA64_BKPT ((unsigned)EC_AA64_BKPT) There's also: (5) change the usage of the shifting macro: #define ARM_EL_EC_SHIFT(x) (((x)+0U) << 26) =2E.. return ARM_EL_EC_SHIFT(EC_AA64_BKPT) | ARM_EL_IL | (imm16 & 0xffff); > I guess there's also > (4) Ignore the problem and trust that the compiler developers will > never decide to use this bit of undefined behaviour. HACKING already implies we assume sane 2's complement behavior of shifts (maybe it's worth another line for this particular case of shifting into the signed bit of a signed result, and figuring out how to shut up clang)= : >> The C language specification defines regions of undefined behavior and= >> implementation defined behavior (to give compiler authors enough leewa= y to >> produce better code). In general, code in QEMU should follow the lang= uage >> specification and avoid both undefined and implementation defined >> constructs. ("It works fine on the gcc I tested it with" is not a vali= d >> argument...) However there are a few areas where we allow ourselves to= >> assume certain behaviors because in practice all the platforms we care= about >> behave in the same way and writing strictly conformant code would be >> painful. These are: >> * you may assume that integers are 2s complement representation >> * you may assume that right shift of a signed integer duplicates >> the sign bit (ie it is an arithmetic shift, not a logical shift) --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --XkkDKBDACDJxkDKN3OGGBwIFfQMrK48Um Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJU1PvDAAoJEKeha0olJ0NqlbcH/jqtJyHFrKGH9og4A1g5ZNM8 ZM9dwTznwSO2Z5BF55HnEHKmdpKWbxH1Co4YNiRP4g1syswojM5gn0J6kNZdvx0H IXoQ6CJP7a3haGXtGT2GcN9X+8i2NfwkmSVeeKF2+PUZ0N95OlKvGBvvkVzbtqC8 moQz9vSC3/CVHgEGpjv3RTpP7i4gMD0LyKiz6xML+Xu9X/nOUDH5BYVfZijkLTOC v/d0wcC6+eoRfAZe2K7FjjgTFH8mK22mqxw36zS23M64Co+RY/8bl2Pf2uJ0v+g4 JgN8Nx1UbEC8BakTz6cTfdaHiSVspuSOyih3KDJoMcS6XcBQJPgLkY2LVT8W3A8= =xSOr -----END PGP SIGNATURE----- --XkkDKBDACDJxkDKN3OGGBwIFfQMrK48Um--