On Wed, 5 Apr 2006, chefren wrote:
>
> We have found an 'interesting interaction' between the gcc compiler and
> OpenBSD's inline assembly definition of ntohs().
>
> The resulting bug in the generated assembly causes corrupted data under
> the following circumstances:
>
> * The 16-bit value from ntohs() is directly assigned to a 32-bit
> variable.
> * The 32-bit variable is a local stack variable.
> * gcc is set to -march=i686
> * OpenBSD 3.8 (gcc 3.3.5)
>
>
> The attached .tar.gz contains detailed information including test code
> and assembly output.
>
> Summary: gcc uses a 16-bit 'movw' instruction to move the ntohs() end
> result to the 32-bit stack variable, which leaves the upper 2 bytes of
> the 32-bit stack variable uninitialized with random garbage.
This has been spotted before. The PR was closed since we do not
support non-standard options to gcc, so it does not affect OpenBSD base.
On the other hand, I find this interesting, since it might be an
indication of other bugs lurking. Good that you provided a simple test
case!
-Otto
>
> The problem was not immediately apparent on Debian Sarge, which also
> uses gcc 3.3.5 (but with different default settings, and no pro-police,
> etc).
>
> This is probably a bug we need to file with the gcc people, but we want
> to give a heads-up to OpenBSD first, and see if this rings a bell here.
>
> (Or yell if we missed something!)
>
> +++chefren
>
> p.s. If the attachment is stripped:
>
> http://idd.nl/test-ntohs.tar.gz
