GCC 4.3.0 Exposes a Kernel Bug

ohxten sends news from earlier this month that GCC 4.3.0's new behavior of not clearing the direction flag before a string operation on x86 systems poses problems with kernels — such as Linux and BSD — that do not clear the direction flag before a signal handler is called, despite the ABI specification.

Comments

Re:so what

[Codifex Maximus]

Ok, I read the article and alot of the comments.

Seems to me the easy and correct thing to do would be to use deprecation. i.e. keep the old functionality for a bit longer and also patch or make the new kernels properly set the flag right now. This way, we move in the right direction and when it's no longer an issue then we drop the functionality in the compiler and rely on the kernel setting the flag like it's supposed to do.

Now, I see why the kernels have not been setting the flag. Why should they when the compiler was doing it? Time to set things right though... in the interests of portability with other environments and compilers. Having the kernels setting the flag starting now would satisfy ABI compatibility with the other compilers AND having gcc continue to cover the flag, by default for a time, would prevent breakage of alot of existing code.

Seems like a no brainer to me. After all, isn't that what deprecation is for?

That's my take on it...

Re:GCC is wrong

[evanbd]

Silly question time...

If this managed to affect both Linux and BSD despite no relevant common code, is Windows affected? I'm guessing OSX is, thanks to its BSD heritage. Has anyone tested either of them, though? How about other OSes?

Re:so what

[Vlad_the_Inhaler]

From what I saw of TFA, this is being done. An updated GCC is being pushed and I suppose that this reversion to the previous behaviour will be backed out again at some point.

Interesting was:

• GCC was the exception in this case - other C compilers always did it this way
• While it affects some programs running under Linux or BSD, this GCC update appears to nuke Hurd completely.