Re: GCC 4.9 considered evil

[Carlos Rafael Giani <dv@pseudoterminal.org>]

[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]

On 08/14/2014 02:46 AM, Khem Raj wrote:
>
>
> On Wednesday, August 13, 2014, Otavio Salvador 
> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
>
>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@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@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.

[-- Attachment #2: Type: text/html, Size: 6825 bytes --]