Date: Sun, 1 Dec 2013 09:59:14 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: Dimitry Andric <dim@freebsd.org>, "current@freebsd.org" <current@freebsd.org> Subject: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds Message-ID: <20131201075914.GE59496@kib.kiev.ua> In-Reply-To: <CAJ-VmonQip5Q%2BDfSd_dba_=g8bZYM9uyhYw8XmhU4wGydnJJtg@mail.gmail.com> References: <20131130135616.GA59496@kib.kiev.ua> <E3E2524B-4423-4962-BFD7-9A81424296F7@FreeBSD.org> <CAJ-VmonQip5Q%2BDfSd_dba_=g8bZYM9uyhYw8XmhU4wGydnJJtg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--6oogbsWdjksf+fv4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 30, 2013 at 04:33:17PM -0800, Adrian Chadd wrote: > On 30 November 2013 15:25, Dimitry Andric <dim@freebsd.org> wrote: > > On 30 Nov 2013, at 14:56, Konstantin Belousov <kostikbel@gmail.com> wro= te: > >> I propose to unconditionally add the switch -fno-strict-overflow to t= he > >> kernel compilation. See the patch at the end of message for exact cha= nge > >> proposed. > >> > >> What does it do. It disallows useless and counter-intuitive behaviour = of > >> the compiler(s) for the signed overflow. Basically, the issue is that > >> the C standard left signed overflow as undefined to allow for different > >> hardware implementation of signess to be used for signed arithmetic. > >> De-facto, all architectures where FreeBSD works or have a chance to be > >> ported, use two-complement signed integer representation, and develope= rs > >> intuition is right about it. > > > > I think this is quite a misrepresentation. Any C compiler is free to do > > whatever it wants whenever it encounters undefined behavior. Some > > behavior is undefined in the C standards, so compilers can do a better > > job at optimization. Sure. And we are free to call such compiler useless and moronic. E.g. the standard explicitely marks any code implementing malloc-like allocator and VM 'forbidden', since it cannot be done without calling undefined behaviour. Should we stop writing the kernel or libc ? > > > > If the optimized code fails to do what the programmer thinks it does, it > > is almost always the programmer's fault, excluding actual compiler bugs > > (which are unavoidable, as all software has bugs). > > > > Basically, if you rely on undefined behavior, you are inventing your own > > de facto language, which is *not* C. That is fine with me, but let's > > not pretend the FreeBSD kernel is written in C then. :-) It is written in C, but no useful program can be written in the pure standard C. We must rely on the assumptions about underlying architecture, and compiler must provide sane access to the features of the underlying architecture to be useful. Just to list a few, - ILP32 or LP64; - ABI; - flat address space with arbitrary arithmetic on the data pointers; - code as data, in the same address space (yes, we patch code at runtime); - non-regular memory, both with additional side-effects when accessed, like register mappings (this cannot be modelled with volatile, think about e.g. address space switch caused by register access); and side-effect free memory with non-WC semantic. This can be continued infinitely. Why _sane_ implementation of signed arithmetic for 2-complement machine, which is just one item in the list above, is tolerated to be crippled ? Esp. since it causes (god forbids) *security* problems systematically ? >=20 > Are you able to have clang/llvm/gcc tell us where/when code is relying > on undefined behaviour? So we can, like, fix them? No, it is impossible. This is similar to the -fno-strict-aliasing. Compiler is sometimes able to note that it cheat on you by applying the undefined behaviour card, but this is not coded in the compiler systematically. And, the biggest problem, routine changes in the optimizer cause different places to become the victim. So the fact that your code is not flagged today does not assure that it would be not crippled tomorrow. >=20 > If there was a way to lint this stuff then yes, please lint it. >=20 > Otherwise we don't have the tools to know whether we're doing sane > things or not. >=20 > (Same with things like strict aliasing..) We do not have the tools, and indeed, same as with strict aliasing. --6oogbsWdjksf+fv4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSmuxRAAoJEJDCuSvBvK1Bnx0QAIZ1uGG+mzFaCRvt96LNsxHK MbpkO88U0A2/ADD4dNJV7uiuUUC7JPpgyqQ+l3pB6Q5jCOZiBA4q/Sr4o6ks/em2 ldfXhYzSiTq5/UOoXkl0qglMovCD8REtFohOAXkTLaHiICm9oezCzpfnLai83dqi utUhJRg4iphJe7ViUIirzMd9eb/RigwKZCIgMWv32ONiJPvFxYfJuupLScapM5RT o6SQmFWXuF+SG1RnzmzckNpzNootR07txhHNnmr5gT/s2+0m2xWhjMOgge8zU7mr qqpY8qb2jMisffgKKGngoHOFpyvIKctn9FtpY0DF4Xol1uo5SUqJCszILVtfNFSZ EM90h099/ZUyAdqEvk2y678FSEk7exjJjkIjL/fo07orJ7qCHq+2jkEe8mCRfYM8 /wiL4xRWHduXOwOFH7IFNzVLG0TnCxSFE8L/34oKxVZuOx6bDhV12rpoZtG3Pa9O j2Cm1nIZ1bX4Tx6OIaZWFfOmqFnuZIg13kaqkmcrmveXAzLr/C2lTQZa86XuI271 C+n/Y+S4xNifhi4ARl5GAkHIkHh58e+Odb/T1KLaAa2pHlAZKoH9+oGexoquo22x cd46QPpzwaubtVIKEdH8P/gjK147+aP+Y+VsOe31MWtmkYYIhniBqNOdrdsiPFHi dgB4KgtKM3ChQX6jC6Sh =fyGV -----END PGP SIGNATURE----- --6oogbsWdjksf+fv4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131201075914.GE59496>