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 <[email protected]> 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 <[email protected]>
> To: Peter Hurley <[email protected]>
> Cc: Nathan Lynch <[email protected]>,
> David Laight <[email protected]>,
> Otavio Salvador <[email protected]>,
> Linus Torvalds <[email protected]>,
> Nicolas Pitre <[email protected]>,
> Linux OMAP Mailing List <[email protected]>,
> [email protected]
> Message-ID: <[email protected]>
> 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
> [email protected]
> http://lists.linaro.org/mailman/listinfo/linaro-toolchain
_______________________________________________
linaro-toolchain mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
