This is one of these eerie moments when you realize that a significant part

of your beliefs are wrong.

In this case, trust in gcc.


When computing the address of a field in a structure on stack, and:
- the offset of the structure relative to the stack pointer
and
- the offset of the field relative to the structure
have no _bits_ in common (for example, accessing field at structure(8)
with the structure at sp(64)), triggers a gcc optimization in the following
improvement:
  (plus (plus (frame_pointer offset_for_structure) offset_for_field))
changing into
  (plus (frame_pointer direct_offset_for_field))

In the aforementioned "no bits in common" case, gcc will use
   (or (plus frame_pointer offset_for_structure) offset_for_field)
which is not necessarily correct, depending on the value of the frame
pointer...


Checking generated assembly code for a kernel compilation pointed out that
ALL architectures were affected by this bug (some, such as m88k, alpha
and sparc64, being much more affected than others, such as vax and m68k).


Our first move was to backport a fix for this found in the gcc 3.x branch,
however it relies upon several microbugfixes scattered around, and produced
a misbehaving kernel on one particular machine. So what goes in with this
commit is just a conservative fix which disables this particular "bitwise or
is fun" optimization.


Problem discovery and analysis by yours truly. Fix by etoh@ and I.
Tested on all supported architectures by various people, including deraadt@,
henning@, mickey@, naddy@ and I.

0 files changed, 0 insertions, 0 deletions