<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/14/2014 03:24 AM, Carlos Rafael
Giani wrote:<br>
</div>
<blockquote cite="mid:53EC723D.5000807@pseudoterminal.org"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 08/14/2014 10:22 AM, Peter A.
Bigot wrote:<br>
</div>
<blockquote cite="mid:53EC71B1.3000200@pabigot.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 08/14/2014 03:12 AM, Carlos
Rafael Giani wrote:<br>
</div>
<blockquote cite="mid:53EC6F53.4070908@pseudoterminal.org"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 08/14/2014 02:46 AM, Khem Raj
wrote:<br>
</div>
<blockquote
cite="mid:CAMKF1soYYaAQ9tY7462=zEgo9urFaaAV-qDk6qhO=8_n0xdDyA@mail.gmail.com"
type="cite"><br>
<br>
On Wednesday, August 13, 2014, Otavio Salvador <<a
moz-do-not-send="true"
href="mailto:otavio@ossystems.com.br">otavio@ossystems.com.br</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed,
Aug 13, 2014 at 6:24 PM, Gary Thomas <<a
moz-do-not-send="true" href="javascript:;"
onclick="_e(event, 'cvml', 'gary@mlbassoc.com')">gary@mlbassoc.com</a>>
wrote:<br>
> I've found that the latest GCC doesn't work very
well, at<br>
> least not on ARM (and obviously other architectures
as well [1])<br>
> When I build Google Chromium browser for my i.MX
boards using<br>
> GCC-4.9.x, no pages can be rendered - massive
bloodshed and<br>
> failures are shown on the console. If I use the
older GCC 4.8.2,<br>
> everything else the same, all is well.<br>
><br>
> Here's my configuration:<br>
> BB_VERSION = "1.23.1"<br>
> BUILD_SYS = "x86_64-linux"<br>
> NATIVELSBSTRING = "Ubuntu-13.10"<br>
> TARGET_SYS = "arm-amltd-linux-gnueabi"<br>
> MACHINE = "teton-p0382"<br>
> DISTRO = "amltd"<br>
> DISTRO_VERSION = "1.6+snapshot-20140812"<br>
> TUNE_FEATURES = "arm armv7a vfp neon
callconvention-hard cortexa9"<br>
> TARGET_FPU = "vfp-neon"<br>
> meta =
"master:86afd7eb7c679eb065706137f28f44248f3fbc5a"<br>
> meta-amltd =
"master:899529b4184dc9e3e291e7fcdbbf157233db056d"<br>
> meta-teton-imx6-p0382 =
"master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"<br>
> meta-fsl-arm =
"master:b0cf5c78c5f98c5977ae556d331e7495648f154c"<br>
> meta-fsl-arm-extra =
"master:12e560967b7136222c325d11633295fe3a0c701c"<br>
> meta-browser =
"master:da93c8e386133a15eff1414d9307c8f2c7a44787"<br>
><br>
> Should this be filed as a bug? I don't have much
data other than it<br>
> simply breaks (and chrome is not the easiest thing to
debug!). Other<br>
> applications seem OK, but I am loathe to trust it...<br>
><br>
> I'm going to hold onto GCC-4.8.x for my $DISTRO at
least (and I hope<br>
> it doesn't vanish like 4.7.x did too quickly).<br>
><br>
> [1]<br>
> <a moz-do-not-send="true"
href="http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken"
target="_blank">http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken</a><br>
><br>
> Note: I've also tried this on qemux86 (a totally
different<br>
> architecture) and chrome bombs just as badly!<br>
<br>
I confirm that GCC 4.9 does NOT work for Chromium 35. At
this moment I<br>
am not aware of any fix for it.</blockquote>
<div><br>
</div>
<div>Again Its a broad brush statement. Something concrete
is needed if some.action is to taken</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
IIRC the Chromium 37 works though.<br>
<br>
</blockquote>
<div><br>
</div>
<div>Well then its less chance.that someone will fix 35 </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> --<br>
Otavio Salvador O.S. Systems<br>
<a moz-do-not-send="true"
href="http://www.ossystems.com.br" target="_blank">http://www.ossystems.com.br</a>
<a moz-do-not-send="true"
href="http://code.ossystems.com.br" target="_blank">http://code.ossystems.com.br</a><br>
Mobile: +55 (53) 9981-7854 Mobile: +1 (347)
903-9750<br>
--<br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a moz-do-not-send="true" href="javascript:;"
onclick="_e(event, 'cvml',
'Openembedded-core@lists.openembedded.org')">Openembedded-core@lists.openembedded.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openembedded.org/mailman/listinfo/openembedded-core"
target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
<br>
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.<br>
<br>
I wouldn't rule out that Linus Torvald's find isn't the cause
here. Look at this part of his message:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
"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."<br>
<br>
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.<br>
</blockquote>
<br>
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.)<br>
<br>
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.<br>
<br>
Peter<br>
<br>
<blockquote cite="mid:53EC6F53.4070908@pseudoterminal.org"
type="cite"> <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
<br>
<br>
To further elaborate, the Chromium developers know about problems
with GCC 4.9. Here is an example: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://code.google.com/p/chromium/issues/detail?id=385729">https://code.google.com/p/chromium/issues/detail?id=385729</a><br>
</blockquote>
<br>
For what little comfort it might give, that one turns out to be a
bug in Chromium that was exposed by GCC 4.9, not a GCC 4.9 bug.
"Still, the root issue exists on every branch and it's sheer chance
that most builds don't appear to be affected."<br>
<br>
<blockquote cite="mid:53EC723D.5000807@pseudoterminal.org"
type="cite"> 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.)<br>
<br>
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.<br>
</blockquote>
<br>
I'm adding the twisted-Torvalds'-knickers patch to both gcc 4.8 and
4.9 in my gcc series.<br>
<br>
Peter<br>
</body>
</html>