Skip site navigation (1)Skip section navigation (2)
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>