[OE-core] GCC 4.9 considered evil
Peter A. Bigot
pab at pabigot.com
Thu Aug 14 19:11:48 UTC 2014
On 08/14/2014 01:14 PM, Carlos Rafael Giani wrote:
> On 08/14/2014 10:22 AM, Peter A. Bigot wrote:
>> On 08/14/2014 03:12 AM, Carlos Rafael Giani wrote:
>>> On 08/14/2014 02:46 AM, Khem Raj wrote:
>>>>
>>>>
>>>> On Wednesday, August 13, 2014, Otavio Salvador
>>>> <otavio at ossystems.com.br <mailto:otavio at ossystems.com.br>> wrote:
>>>>
>>>> On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary at mlbassoc.com
>>>> <javascript:;>> wrote:
>>>> > I've found that the latest GCC doesn't work very well, at
>>>> > least not on ARM (and obviously other architectures as well [1])
>>>> > When I build Google Chromium browser for my i.MX boards using
>>>> > GCC-4.9.x, no pages can be rendered - massive bloodshed and
>>>> > failures are shown on the console. If I use the older GCC 4.8.2,
>>>> > everything else the same, all is well.
>>>> >
>>>> > Here's my configuration:
>>>> > BB_VERSION = "1.23.1"
>>>> > BUILD_SYS = "x86_64-linux"
>>>> > NATIVELSBSTRING = "Ubuntu-13.10"
>>>> > TARGET_SYS = "arm-amltd-linux-gnueabi"
>>>> > MACHINE = "teton-p0382"
>>>> > DISTRO = "amltd"
>>>> > DISTRO_VERSION = "1.6+snapshot-20140812"
>>>> > TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard
>>>> cortexa9"
>>>> > TARGET_FPU = "vfp-neon"
>>>> > meta =
>>>> "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
>>>> > meta-amltd =
>>>> "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
>>>> > meta-teton-imx6-p0382 =
>>>> "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
>>>> > meta-fsl-arm =
>>>> "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
>>>> > meta-fsl-arm-extra =
>>>> "master:12e560967b7136222c325d11633295fe3a0c701c"
>>>> > meta-browser =
>>>> "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>>>> >
>>>> > Should this be filed as a bug? I don't have much data other
>>>> than it
>>>> > simply breaks (and chrome is not the easiest thing to
>>>> debug!). Other
>>>> > applications seem OK, but I am loathe to trust it...
>>>> >
>>>> > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and
>>>> I hope
>>>> > it doesn't vanish like 4.7.x did too quickly).
>>>> >
>>>> > [1]
>>>> >
>>>> http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>>>> >
>>>> > Note: I've also tried this on qemux86 (a totally different
>>>> > architecture) and chrome bombs just as badly!
>>>>
>>>> I confirm that GCC 4.9 does NOT work for Chromium 35. At this
>>>> moment I
>>>> am not aware of any fix for it.
>>>>
>>>>
>>>> Again Its a broad brush statement. Something concrete is needed if
>>>> some.action is to taken
>>>>
>>>>
>>>> IIRC the Chromium 37 works though.
>>>>
>>>>
>>>> Well then its less chance.that someone will fix 35
>>>>
>>>> --
>>>> Otavio Salvador O.S. Systems
>>>> http://www.ossystems.com.br http://code.ossystems.com.br
>>>> Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core at lists.openembedded.org <javascript:;>
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>
>>>>
>>>>
>>>
>>>
>>> The problem is that narrowing down is very difficult, since the
>>> problems manifest themselves as seemingly random stack corruptions.
>>> I have tried to dig into it, but got nowhere. Pointers suddenly
>>> became null for no apparent reason, or were corrupted, free() calls
>>> failed, values on the stack suddenly changed without being modified
>>> by the code etc.
>>>
>>> I wouldn't rule out that Linus Torvald's find isn't the cause here.
>>> Look at this part of his message:
>>>
>>> "The x86-64 ABI specifies a 128-byte red-zone under the stack
>>> pointer, and this is ok by that limit. It looks like it's illegal
>>> (136 > 128), but the fact is, we've had four "pushq"s to update %rsp
>>> since loading the frame pointer, so it's just *barely* legal with
>>> the red-zoning."
>>>
>>> Perhaps gcc is pushing further outside of the red zone bounds, thus
>>> causing the problems. No idea how to check for that at the moment
>>> though.
>>
>> Simplest would be to apply the upstream fix to Yocto's gcc and see if
>> that helps. You'd want commit
>> 556537c4ad0df4cbebb74197bb2bdea75cf5dd35 from
>> git://gcc.gnu.org/git/gcc.git. (The patch went into gcc-4_9-branch
>> one day after 4.9.1 was released.)
>>
>> I'd add it to the current set but ATT Khem and I both have pending
>> patches that touch the same gcc files, so it'd just increase the
>> conflicts.
>>
>> Peter
>
> Are you sure this is the right patch? Commit message:
>
> [PATCH] 2014-07-17 Richard Biener <rguenther at suse.de>
>
> PR rtl-optimization/61801
> * sched-deps.c (sched_analyze_2): For ASM_OPERANDS and
> ASM_INPUT don't set reg_pending_barrier if it appears in a
> debug-insn.
>
> It does not apply cleanly on gcc in either master or master-next .
> Patching ChangeLog fails. I will try to use it with the ChangeLog
> patch part omitted.
Yes, I'm sure. That's the bug referenced in Torvald's Linux commit
working around the rant-inducing behavior.
Unmodified upstream patches for gcc never apply cleanly because they are
based on unreleased versions with ChangeLog entries that aren't present
in the released versions. The V2 series I just sent includes the patch
directly from upstream gcc-4_8-branch and gcc-4_9-branch, with ChangeLog
pieces stripped.
Note that there's no reason to believe this will make chromium 35 any
more stable, but it might avert issues people running unpatched Linux
kernels could run into.
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140814/942af7a6/attachment-0002.html>
More information about the Openembedded-core
mailing list