From: Martin Jansa <martin.jansa@gmail.com>
To: Carlos Rafael Giani <dv@pseudoterminal.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: GCC 4.9 considered evil
Date: Fri, 15 Aug 2014 16:53:14 +0200 [thread overview]
Message-ID: <20140815145314.GH22747@jama> (raw)
In-Reply-To: <53EC723D.5000807@pseudoterminal.org>
[-- Attachment #1: Type: text/plain, Size: 13124 bytes --]
On Thu, Aug 14, 2014 at 10:24:29AM +0200, 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@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.
> >
> > 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.
You're not seeing this with 37* chromium builds?
It's repeated in all world builds for some time.
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_mprintf' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_exec' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_free' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_reset' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_finalize' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_close' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_step' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_column_int' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_prepare_v2' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_bind_blob' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_bind_int' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_bind_text' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_open' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_busy_timeout' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_column_bytes' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_column_blob' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_file_control' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_temp_directory' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: error: treating warnings as errors
| collect2: error: ld returned 1 exit status
| ninja: build stopped: subcommand failed.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/jenkins/oe/world/shr-core/tmp-eglibc/work/core2-64-oe-linux/chromium/37.0.2062.0-r0/temp/log.do_compile.14955)
NOTE: recipe chromium-37.0.2062.0-r0: task do_compile: Failed
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
next prev parent reply other threads:[~2014-08-15 14:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 21:24 GCC 4.9 considered evil Gary Thomas
2014-08-13 22:54 ` Khem Raj
2014-08-13 23:25 ` Otavio Salvador
2014-08-14 0:46 ` Khem Raj
2014-08-14 8:12 ` Carlos Rafael Giani
2014-08-14 8:22 ` Peter A. Bigot
2014-08-14 8:24 ` Carlos Rafael Giani
2014-08-14 10:02 ` Peter A. Bigot
2014-08-14 10:44 ` Gary Thomas
2014-08-15 14:53 ` Martin Jansa [this message]
2014-08-14 18:14 ` Carlos Rafael Giani
2014-08-14 19:11 ` Peter A. Bigot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140815145314.GH22747@jama \
--to=martin.jansa@gmail.com \
--cc=dv@pseudoterminal.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox