Hello, chromium builds fine, but on start fails with: $ /usr/bin/chromium Illegal instruction gdb shows: Program received signal SIGILL, Illegal instruction. [Switching to Thread 0xaeed4b40 (LWP 10200)] 0x82ffe564 in ?? () (gdb) x/i $pc => 0x82ffe564: movlpd 0x8380e598,%xmm2 movlpd is from SSE2 instruction set, host CPU is Athlon-XP with no SSE2 support.
Created attachment 322228 [details] emerge --info www-client/chromium
I managed to compile chromium with -ggdb, this requires -Wl,--reduce-memory-overheads -Wl,--no-keep-memory in $LDFLAGS, otherwise ld exceeds 3GB userspace memory limit. Here is a full backtrace: Program received signal SIGILL, Illegal instruction. [Switching to Thread 0xaeed4b40 (LWP 28570)] qcms_profile_sRGB () at third_party/qcms/src/iccread.c:983 983 D65 = white_point_from_temp(6504); (gdb) bt #0 qcms_profile_sRGB () at third_party/qcms/src/iccread.c:983 #1 0x81974e2f in qcmsOutputDeviceProfile () at third_party/WebKit/Source/WebCore/platform/image-decoders/ImageDecoder.h:327 #2 createColorTransform (hasAlpha=true, colorProfile=..., this=<optimized out>) at third_party/WebKit/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:196 #3 WebCore::PNGImageDecoder::headerAvailable (this=0xaa706880) at third_party/WebKit/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:346 #4 0xb584b39e in ?? () from /usr/lib/libpng15.so.15 #5 0xb584b9e7 in ?? () from /usr/lib/libpng15.so.15 #6 0xb584c904 in ?? () from /usr/lib/libpng15.so.15 #7 0xb584c9a4 in png_process_data () from /usr/lib/libpng15.so.15 #8 0x81973beb in WebCore::PNGImageReader::decode (this=0xaa706970, data=..., sizeOnly=true) at third_party/WebKit/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:162 #9 0x8197447a in WebCore::PNGImageDecoder::decode (this=0xaa706880, onlySize=true) at third_party/WebKit/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:544 #10 0x819747ba in WebCore::PNGImageDecoder::isSizeAvailable (this=0xaa706880) at third_party/WebKit/Source/WebCore/platform/image-decoders/png/PNGImageDecoder.cpp:239 #11 0x81693c2c in WebKit::WebImage::fromData (data=..., desiredSize=...) at third_party/WebKit/Source/WebKit/chromium/src/WebImageSkia.cpp:56 #12 0x8252f8b0 in webkit_glue::ImageDecoder::Decode (this=0xaeed3294, data=0xaa706c64 "\211PNG\r\n\032\n", size=3680) at webkit/glue/image_decoder.cc:29 #13 0x826ba0a1 in ImageLoadingTracker::ImageLoader::LoadOnFileThread (this=0x843e0918, resource=..., max_size=..., id=0) at chrome/browser/extensions/image_loading_tracker.cc:113 #14 0x826b9753 in Run (a2=..., a1=..., object=<optimized out>, this=<synthetic pointer>, a3=<optimized out>) at ./base/bind_internal.h:311 #15 MakeItSo (a3=..., a2=..., runnable=..., a1=<optimized out>, a4=<optimized out>) at ./base/bind_internal.h:958 #16 base::internal::Invoker<4, base::internal::BindState<base::internal::RunnableAdapter<void (ImageLoadingTracker::ImageLoader::*)(ExtensionResource const&, gfx::Size const&, int)>, void (ImageLoadingTracker::ImageLoader*, ExtensionResource const&, gfx::Size const&, int), void (ImageLoadingTracker::ImageLoader*, ExtensionResource, gfx::Size, int)>, void (ImageLoadingTracker::ImageLoader*, ExtensionResource const&, gfx::Size const&, int)>::Run(base::internal::BindStateBase*) (base=0x843e0928) at ./base/bind_internal.h:1571 #17 0x810f7a23 in Run (this=0xaeed3b10) at ./base/callback.h:388 #18 MessageLoop::RunTask (this=0xaeed3fec, pending_task=...) at base/message_loop.cc:460 #19 0x810fc8ec in MessageLoop::DeferOrRunPendingTask (this=0xaeed3fec, pending_task=...) at base/message_loop.cc:472 #20 0x810fce9f in DoWork (this=<optimized out>) at base/message_loop.cc:648 #21 MessageLoop::DoWork (this=0xaeed3fec) at base/message_loop.cc:627 #22 0x810d02d0 in base::MessagePumpLibevent::Run (this=0xb0f00d60, delegate=0xaeed3fec) at base/message_pump_libevent.cc:239 #23 0x810fb7c1 in MessageLoop::RunInternal (this=0xaeed3fec) at base/message_loop.cc:419 #24 0x81114bda in base::RunLoop::Run (this=0xaeed3db4) at base/run_loop.cc:45 #25 0x810f70f8 in MessageLoop::Run (this=0xaeed3fec) at base/message_loop.cc:299 #26 0x827df0bc in content::BrowserThreadImpl::FileThreadRun (this=0x84119a48, message_loop=0xaeed3fec) #27 0x827df6dc in content::BrowserThreadImpl::Run (this=0x84119a48, message_loop=0xaeed3fec) at content/browser/browser_thread_impl.cc:169 #28 0x8112f282 in base::Thread::ThreadMain (this=0x84119a48) at base/threading/thread.cc:169 #29 0x8112af19 in base::(anonymous namespace)::ThreadFunc (params=0x8411c1b8) at base/threading/platform_thread_posix.cc:65 #30 0xb7f8ed7f in start_thread () from /lib/libpthread.so.0 #31 0xb51ae9be in clone () from /lib/libc.so.6 (gdb)
Looks like the problem with qcms is that only transform-sse1.c must be compiled with -msse and transform-sse2.c with -msse -msse2. But instead all files are compiled with -msse -msse2 which results in sse2 optimized code in the place where it can't be executed. (transform-sse2.c is used only if sse2 support is detected on run-time).
I tried the latest 23.0.1243.2 — the same issue. I can fix the issue for this very problem, but chromium unconditionally forces -mmmx -msse -msse3 anyplace in the code, so this problem may and will arise again for other chromium, compiler and CPU versions. The proper solution will be to honor CPU-related USE flags, especially mmx and sse families.
Created attachment 322483 [details, diff] chromium-no-sse2.patch The proper fix will be to use CPU-related GCC flags only on files that need them to compile (like transform-sse2.c), but I can't find any documented way to specify file-specific CFLAGS in gyp. (This is so annoying that many large projects reinvent wheels by using their own hand-made non-universal build system.) That's why I used GCC pragmas to achieve the same effect: for all files except SSE-specific ones SSE2 is disabled if USE="sse2" is not set. I need to fix all "common" qcms files, not only iccread.c, because other files had SSE2 code too. With this and the following ebuild patch chromium 22.0.1229.14 works fine for me on Athlon-XP, though this solution is hackish and dirty.
Created attachment 322485 [details, diff] chromium-22.0.1229.14.ebuild.patch Apply no-sse2 patch only on USE demand.
Please file an upstream bug (http://new.crbug.com) and post the link here. We can't take your patch, this should be fixed upstream and then eventually backported. By the way, ebuilds should apply patches unconditionally. Thanks for reporting this sse2-related issue.
I filed an upstream bug: https://code.google.com/p/chromium/issues/detail?id=146154 > By the way, ebuilds should apply patches unconditionally. Hmm, may be this is a desirable behaviour, but not really always possible. USE flags "vanilla" or "hardened" are good examples to start with. Also sometimes several patches can't be applied at the same time and user has to chose via USE flags. As for this case, in order to make no-sse2 patch unconditional we need to know about CPU SSE2 capabilities at the compile time. This will require very serious alternation of the gyp build system and will do no good. Anyway upstream must fix this in gyp, they will not accept gcc-dependent patch. Proposed patch is only a temporary solution, I posted it in a hope to help people with similar issue, because I wasted three days to find and fix it: chromium takes very long to compile on old hardware, even with distcc.
Issue has been reported as fixed upstream.
