Date: Thu, 19 Dec 2013 12:38:28 +0100 From: Oliver Pinter <oliver.pntr@gmail.com> To: Stefan Esser <se@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, current@freebsd.org Subject: Re: SOLVED: Problem with -fno-strict-overflow (was: Re: RFC: (Unconditionally) enable -fno-strict-overflow for kernel builds) Message-ID: <CAPjTQNHF4cs5NQ584q4ZKXaK_CJxR64UWTJdZ8N1hz1UkL55Cg@mail.gmail.com> In-Reply-To: <52B2B960.7040607@freebsd.org> References: <20131130135616.GA59496@kib.kiev.ua> <52B2B960.7040607@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/19/13, Stefan Esser <se@freebsd.org> wrote: > Am 30.11.2013 14:56, schrieb Konstantin Belousov: >> I propose to unconditionally add the switch -fno-strict-overflow >> to the kernel compilation. See the patch at the end of message for >> exact change 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 developers intuition is right >> about it. >> >> The compiler authors take the undefined part there as a blanket to >> perform optimizations which are assuming that signed overflow >> cannot happen. The problem with that approach is that typical >> checks for bounds are exactly the place where the overflow can >> happen. Instead of making some artificial example, I would just >> point to my own r258088 and r258397. >> >> What makes the things much worse is that the behaviour is highly >> depended on the optimization level of the exact version of >> compiler. >> >> What other projects did in this regard. They turned the same knob >> unconditionally. I can point at least to Linux kernel and >> Postgresql. Python uses -fwrapv, which is equivalent to the >> -fno-strict-overflow on the two-complement machines. Linux used >> -fwrapv before switched to -fno-strict-overflow. > > Hi Konstantin, > > you may put back -fno-strict-overflow after I found and fixed the > problem uncovered by enabling it in -CURRENT (SVN rev. 259609). > > The problem was an overflow in the conversion of timeout values to > sbintine, which lead to negative values being detected with > -fno-strict-overflow, while the compiler performed the signedness > test before the multiplication, without that option. > > I found that timeout values of more than 1000 years were requested > by some programs, which are now capped at 68 years (the maximum that > can be represented by sbintime, 2^31 seconds). > > So, -fno-strict-overflow has already proved itself to be useful > in uncovering a bug that would have been hard to find, otherwise. > I have a plan, to port this or like this plugin to llvm/clang in the near future: http://www.grsecurity.net/~ephox/overflow_plugin/ > Regards, STefan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPjTQNHF4cs5NQ584q4ZKXaK_CJxR64UWTJdZ8N1hz1UkL55Cg>