Probably because AsmJS.cpp is used/compiled inconditionally, while it should be within some ENABLE_ION in js/src/Makefile.in : In file included from /home/landry/src/mozilla-central/js/src/ion/AsmJSModule.h:12:0, from /home/landry/src/mozilla-central/js/src/ion/AsmJS.cpp:11: /home/landry/src/mozilla-central/js/src/ion/RegisterSets.h:461:2: error: #error "Bad architecture" /home/landry/src/mozilla-central/js/src/ion/RegisterSets.h:497:2: error: #error "Bad architecture" /home/landry/src/mozilla-central/js/src/ion/RegisterSets.h:547:2: error: #error "Bad architecture" In file included from /home/landry/src/mozilla-central/js/src/ion/RegisterSets.h:11:0, from /home/landry/src/mozilla-central/js/src/ion/AsmJSModule.h:12, from /home/landry/src/mozilla-central/js/src/ion/AsmJS.cpp:11: /home/landry/src/mozilla-central/js/src/ion/Registers.h:31:13: error: 'Registers' does not name a type /home/landry/src/mozilla-central/js/src/ion/Registers.h:32:13: error: 'Codes' does not name a type /home/landry/src/mozilla-central/js/src/ion/Registers.h:33:13: error: 'Registers' in namespace 'js::ion' does not name a type /home/landry/src/mozilla-central/js/src/ion/Registers.h:34:5: error: 'Code' does not name a type /home/landry/src/mozilla-central/js/src/ion/Registers.h:41:5: error: 'Code' does not name a type
Created attachment 725745 [details] [diff] [review] wip patch This wip patch allows me to build js/src. Not sure it's the best way to go... Building m-c to check the whole thing.
My goal with having AsmJS.cpp always be built is that we can always call CompileAsmJS from the parser so that it can always issue a warning when "use asm" is present. The goal is non-silent failure. Instead of the patch you posted, can you instead put the relevant #includes inside AsmJS.cpp inside the existing #ifdef JS_ASMJS? (JS_ASMJS is a restriction of JS_ION; see AsmJS.h.)
Created attachment 725757 [details] [diff] [review] #ifdef out ion includes / asmjs code This one allows js to build, and all jsapi-tests but one pass (but it also failed before) so this should be better. Not really sure where to #ifdef out stuff in AsmJSLink.cpp.....
I realized, looking at this patch that the way I have it set up will just continually break powerpc and you'll keep having to file these bugs. I think your first approach was the right way to go; sorry for the misdirection! Two nits on that patch: switch #if ENABLE_ION for #ifdef JS_ION and I think you'll want to implement isAsmJSCompilationAvailable() in TestingFunctions.cpp #ifndef JS_ION so that isAsmJSCompilationAvailable() is always defined and usable.
Could you confirm that this cset fixes --disable-ion for you? https://hg.mozilla.org/integration/mozilla-inbound/rev/7e13a94a3f3b
I had a slightly similar cset in my mq, built it last night but ffx badly segfaults at startup. Of course trying to load the core in gdb or run firefox in gdb blows gdb too, so it's hardly debuggable. The js engine itself should be fine, since all jsapi-tests but one passes fine - so the crash might be unrelated. I also have patches from bugs 849253 and 817042 in my queue (the former is also needed to fix a build failure), so i'll retry tonight with a clean tree and only 849253 on top of inbound tip.
I am able to build on ppc64 with these changes (m-c from the 23'rd) + 851859 , 849253(+ extra fixes I mention on this bug that didn't make the commit) and 846986 Firefox starts fine and I can view an initial page without issues. Firefox often hangs when I try to view a second or third page but I think that is unrelated to Odinmonkey. I will kick off an updated build on my ppc32 machine where things tend to work better.
The ppc32 build works on m-c with your patch(with the same other fixes applied as above) and doesn't hang.
Comment on attachment 725757 [details] [diff] [review] #ifdef out ion includes / asmjs code clearing, since I think this patch is out of date
this got fixed by the no bug cset... no idea which target/milestone this was though