[OE-core] GCC 4.9 considered evil
Carlos Rafael Giani
dv at pseudoterminal.org
Thu Aug 14 08:24:29 UTC 2014
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
>
>>
>>
>
>
>
To further elaborate, the Chromium developers know about problems with
GCC 4.9. Here is an example:
https://code.google.com/p/chromium/issues/detail?id=385729
Note that while a build of Chromium 37 works, I've had internal compiler
errors happen. I actually had to re-run the run.do_compile script about
30 times until the build finished (the ICE's happen only sometimes, so
repeated attempts at compiling eventually yields a result.)
Thanks for the link. I'll try it out when I have the time. Aside from
that, I recommend to keep the GCC 4.8 recipes for the time being. At
least they should not be removed as quickly as the 4.7 ones.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140814/d3a48c3f/attachment-0002.html>
More information about the Openembedded-core
mailing list