lkml.org 
[lkml]   [2017]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL] gcc-plugins updates for v4.13-rc1
On 5 July 2017 at 20:07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Hmm. Completely unrelated comment, and this may not be a gcc 'plugin'
> issue as much as a more general gcc question, but I suspect a plugin
> could do it.
>
> For the kernel, we already really ignore some of the more idiotic C
> standard rules that introduce pointless undefined behavior: things
> like the strict aliasing rules are just insane, and the "overflow is
> udnefined" is bad too. So we use
>
> -fno-strict-aliasing
> -fno-strict-overflow
> -fno-delete-null-pointer-checks
>
> to basically say "those optimizations are fundamentally stupid and
> wrong, and only encourage compilers to generate random code that
> doesn't actually match the source code".
>
> And I suspect one other undefined behavior is the one we _try_ to warn
> about, but where the compiler is not always good enough to give valid
> warnings - uninitialized automatic variables.
>
> Maybe we could have gcc just always initialize variables to zero. Not
> just static ones, but the automatic variables too. And maybe it
> wouldn't generate much extra code, since gcc will see the real
> initialization, and the extra hardening against random behavior will
> just go away - so this might be one of those cheap things where we
> just avoid undefined behavior and avoid leaking old stack contents.
>

At the language level, I would be surprised if the compiler exploits
this as undefined behaviour, i.e., that it would assume a convenient
[for the compiler] fixed value for a variable in cases where it can
prove that it has not been initialised. And at the logical level, zero
may not always be a suitable default, this highly depends on the
particular code sequence.

So while I think it may be useful for robustness, to avoid erratic
behavior or exploitable interactions between different parts of the
code, my estimation is that it wouldn't make a great deal of
difference, given that the logic that allows the compiler to 'see the
real initialization' is the same logic that warns us if it is lacking,
and so in a warning free build, no init sequences should have been
emitted to begin with.

\
 
 \ /
  Last update: 2017-07-05 22:41    [W:0.058 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site