FYI.
The whole thread is available here: http://article.gmane.org/gmane.linux.ports.arm.omap/119412
---------- Forwarded message ---------- Date: Thu, 16 Oct 2014 01:18:01 +0100 From: Russell King - ARM Linux linux@arm.linux.org.uk To: Peter Hurley peter@hurleysoftware.com Cc: Nathan Lynch Nathan_Lynch@mentor.com, David Laight David.Laight@ACULAB.COM, Otavio Salvador otavio@ossystems.com.br, Linus Torvalds torvalds@linux-foundation.org, Nicolas Pitre nico@fluxnic.net, Linux OMAP Mailing List linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Message-ID: 20141016001801.GQ12379@n2100.arm.linux.org.uk Subject: Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On Wed, Oct 15, 2014 at 06:18:30PM -0400, Peter Hurley wrote:
On 10/15/2014 05:56 PM, Russell King wrote:
I was in two minds whether to include 4.8.3 as Linaro released a buggy toolchain which identifies itself as 4.8.3, but I decided that's also a distro problem. IMHO Linaro should really think about taking that compiler down given the seriousness of this bug and it being indistinguishable from the fixed stock version.
Maybe it's unfair to blame them; Linaro just took a snapshot and released what was there.
If gcc is going to retain the "change release number then add all the new features" model, some kind of prerelease indicator would help eliminate this kind of problem. And that indicator should be both a preprocessor define and parseable from the command line :)
My comment is not to attribute blame to them, my comment is entirely on a technical level.
My reasoning is that the bug is just as prevalent in userspace, though it will occur less often. Any program which uses signal handlers is a candidate for exactly the same kind of corruption, since you can receive that signal between the point that the stack pointer is modified and the function loads the parent context.
Of course, there are ways around that: don't use signal handlers, or if you do, use alternate signal stacks. Neither of those can be guaranteed for any program though.
So, let me put this another way: a compiler with this bug is _completely_ unsuitable for use for compiling programs for use under the Linux kernel _as well_ as the Linux kernel itself.
The difference is that the Linaro compilers come with an expectation that they are usable on ARM... whereas stock versions cover a lot more and so the ARM arch is probably very small number of their users.
Hence why I recommend that Linaro takes down their buggy compiler. Their 4.8.3 version should not be used *anywhere*, just the same as the stock 4.8 to 4.8.2 inclusive should also not be used anywhere on ARM either.
Hi Nicolas,
thanks for bringing this to our knowledge.
The fix for PR58854 was included in our releases since the GCC 4.8-2013.12 which is based on a 4.8.3 prerelease version (at svn revision 205577). As we are doing monthly releases based on a revision of the related FSF branch, using GCC_VERSION (__GNUC__, __GNUC_MINOR,__GNUC_PATCHLEVEL) is not accurate enough to identify the release version (all our releases between November 2013 and May 2014 will be 4.8.3) the __VERSION__ predefined macro is a bit more accurate here ("4.8.3 20131202 (prerelease)") but not completely satisfactory.
I completely agree that we should at least mention in our impacted releases download pages that this bug is present.
I'm not a subscriber of this mailing list, so feel free to answer and add me in CC if needed.
Cheers, Yvan
On 16 October 2014 04:24, Nicolas Pitre nicolas.pitre@linaro.org wrote:
FYI.
The whole thread is available here: http://article.gmane.org/gmane.linux.ports.arm.omap/119412
---------- Forwarded message ---------- Date: Thu, 16 Oct 2014 01:18:01 +0100 From: Russell King - ARM Linux linux@arm.linux.org.uk To: Peter Hurley peter@hurleysoftware.com Cc: Nathan Lynch Nathan_Lynch@mentor.com, David Laight David.Laight@ACULAB.COM, Otavio Salvador otavio@ossystems.com.br, Linus Torvalds torvalds@linux-foundation.org, Nicolas Pitre nico@fluxnic.net, Linux OMAP Mailing List linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Message-ID: 20141016001801.GQ12379@n2100.arm.linux.org.uk Subject: Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On Wed, Oct 15, 2014 at 06:18:30PM -0400, Peter Hurley wrote:
On 10/15/2014 05:56 PM, Russell King wrote:
I was in two minds whether to include 4.8.3 as Linaro released a buggy toolchain which identifies itself as 4.8.3, but I decided that's also a distro problem. IMHO Linaro should really think about taking that compiler down given the seriousness of this bug and it being indistinguishable from the fixed stock version.
Maybe it's unfair to blame them; Linaro just took a snapshot and released what was there.
If gcc is going to retain the "change release number then add all the new features" model, some kind of prerelease indicator would help eliminate this kind of problem. And that indicator should be both a preprocessor define and parseable from the command line :)
My comment is not to attribute blame to them, my comment is entirely on a technical level.
My reasoning is that the bug is just as prevalent in userspace, though it will occur less often. Any program which uses signal handlers is a candidate for exactly the same kind of corruption, since you can receive that signal between the point that the stack pointer is modified and the function loads the parent context.
Of course, there are ways around that: don't use signal handlers, or if you do, use alternate signal stacks. Neither of those can be guaranteed for any program though.
So, let me put this another way: a compiler with this bug is _completely_ unsuitable for use for compiling programs for use under the Linux kernel _as well_ as the Linux kernel itself.
The difference is that the Linaro compilers come with an expectation that they are usable on ARM... whereas stock versions cover a lot more and so the ARM arch is probably very small number of their users.
Hence why I recommend that Linaro takes down their buggy compiler. Their 4.8.3 version should not be used *anywhere*, just the same as the stock 4.8 to 4.8.2 inclusive should also not be used anywhere on ARM either.
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
linaro-toolchain@lists.linaro.org
-
Nicolas Pitre -
Yvan Roux