RESOLVED FIXED 123809
Build failure when disabling JIT, YARR_JIT, and ASSEMBLER
https://bugs.webkit.org/show_bug.cgi?id=123809
Summary Build failure when disabling JIT, YARR_JIT, and ASSEMBLER
Emilio Pozuelo Monfort
Reported 2013-11-05 10:06:01 PST
On platforms that don't support MacroAssembler (e.g. powerpc), we disable it (and JIT/YARR_JIT). This worked fine until 2.3.1 which fails to build. I suppose this is a missing #if ENABLE(ASSEMBLER) or similar, but I haven't investigated deeper. The build failure is: g++-4.8 -DHAVE_CONFIG_H -I. -I.. -Wall -W -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions -DBUILDING_CAIRO__ -DBUILDING_GTK__ -I../Source -I../Source/JavaScriptCore -I../Source/JavaScriptCore/API -I../Source/JavaScriptCore/ForwardingHeaders -I../Source/JavaScriptCore/assembler -I../Source/JavaScriptCore/bytecode -I../Source/JavaScriptCore/bytecompiler -I../Source/JavaScriptCore/debugger -I../Source/JavaScriptCore/dfg -I../Source/JavaScriptCore/disassembler -I../Source/JavaScriptCore/ftl -I../Source/JavaScriptCore/heap -I../Source/JavaScriptCore/interpreter -I../Source/JavaScriptCore/jit -I../Source/JavaScriptCore/llint -I../Source/JavaScriptCore/parser -I../Source/JavaScriptCore/profiler -I../Source/JavaScriptCore/runtime -I../Source/JavaScriptCore/tools -I../Source/JavaScriptCore/yarr -I./DerivedSources/JavaScriptCore -I../Source/WTF -D_FORTIFY_SOURCE=2 -DENABLE_JIT=0 -DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -Wl,--as-needed -gstabs -pthread -std=c++11 -Wno-c++11-compat -O2 -D_FORTIFY_SOURCE=2 -MT Source/JavaScriptCore/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o -MD -MP -MF Source/JavaScriptCore/llint/.deps/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.Tpo -c -o Source/JavaScriptCore/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o `test -f 'Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp' || echo '../'`Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp In file included from ../Source/JavaScriptCore/bytecode/ValueRecovery.h:30:0, from ../Source/JavaScriptCore/bytecode/CodeOrigin.h:32, from ../Source/JavaScriptCore/bytecode/CodeBlock.h:41, from ../Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:29: ../Source/JavaScriptCore/jit/GPRInfo.h:201:43: error: expected ')' before 'address' JSValueSource(MacroAssembler::Address address) ^ ../Source/JavaScriptCore/jit/GPRInfo.h:269:5: error: 'Address' in 'class MacroAssembler' does not name a type MacroAssembler::Address asAddress(unsigned additionalOffset = 0) const { return MacroAssembler::Address(base(), offset() + additionalOffset); } ^ make[1]: *** [Source/JavaScriptCore/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o] Error 1 Full build log: https://buildd.debian.org/status/fetch.php?pkg=webkitgtk&arch=powerpc&ver=2.3.1-1&stamp=1383673445
Attachments
the patch. (5.09 KB, patch)
2013-11-23 11:00 PST, Mark Lam
ggaren: review+
eflews.bot: commit-queue-
patch 2: Need to fix the build when disabling the DISASSEMBLER as well. (12.00 KB, patch)
2013-12-02 12:02 PST, Mark Lam
ggaren: review+
Csaba Osztrogonác
Comment 1 2013-11-14 03:39:25 PST
Are you sure if it is an issue on ToT WebKit? Here is a similar bug report: https://bugs.webkit.org/show_bug.cgi?id=123317
Emilio Pozuelo Monfort
Comment 2 2013-11-14 03:57:03 PST
I haven't tested with tot, I'll do so beginning of next week and report back.
Iain Lane
Comment 3 2013-11-14 05:51:38 PST
I just tested trunk & got a similar failure: g++-4.8 -DHAVE_CONFIG_H -I. -Wall -W -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions -DBUILDING_CAIRO__ -DBUILDING_GTK__ -I./Source -I./Source/JavaScriptCore -I./Source/JavaScriptCore/API -I./Source/JavaScriptCore/ForwardingHeaders -I./Source/JavaScriptCore/assembler -I./Source/JavaScriptCore/bytecode -I./Source/JavaScriptCore/bytecompiler -I./Source/JavaScriptCore/debugger -I./Source/JavaScriptCore/dfg -I./Source/JavaScriptCore/disassembler -I./Source/JavaScriptCore/ftl -I./Source/JavaScriptCore/heap -I./Source/JavaScriptCore/interpreter -I./Source/JavaScriptCore/jit -I./Source/JavaScriptCore/llint -I./Source/JavaScriptCore/parser -I./Source/JavaScriptCore/profiler -I./Source/JavaScriptCore/runtime -I./Source/JavaScriptCore/tools -I./Source/JavaScriptCore/yarr -I./DerivedSources/JavaScriptCore -I./Source/WTF -D_FORTIFY_SOURCE=2 -DENABLE_JIT=0 -DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -Wl,--as-needed -gstabs -pthread -std=c++11 -Wno-c++11-compat -O2 -D_FORTIFY_SOURCE=2 -MT Source/JavaScriptCore/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o -MD -MP -MF Source/JavaScriptCore/llint/.deps/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.Tpo -c -o Source/JavaScriptCore/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o `test -f 'Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp' || echo './'`Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp In file included from ./Source/JavaScriptCore/bytecode/ValueRecovery.h:30:0, from ./Source/JavaScriptCore/bytecode/CodeOrigin.h:32, from ./Source/JavaScriptCore/bytecode/CodeBlock.h:42, from Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:29: ./Source/JavaScriptCore/jit/GPRInfo.h:201:43: error: expected ‘)’ before ‘address’ JSValueSource(MacroAssembler::Address address) ^ ./Source/JavaScriptCore/jit/GPRInfo.h:269:5: error: ‘Address’ in ‘class MacroAssembler’ does not name a type MacroAssembler::Address asAddress(unsigned additionalOffset = 0) const { return MacroAssembler::Address(base(), offset() + additionalOffset); } ^ In file included from ./Source/WTF/wtf/PossiblyNull.h:29:0, from ./Source/WTF/wtf/FastMalloc.h:27, from ./Source/JavaScriptCore/config.h:60, from Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:26: ./Source/JavaScriptCore/jit/GPRInfo.h:772:16: error: ‘GPRInfo’ has not been declared COMPILE_ASSERT(GPRInfo::regT0 == GPRInfo::returnValueGPR, regT0_must_equal_returnValueGPR); ^ ./Source/WTF/wtf/Assertions.h:325:50: note: in definition of macro ‘COMPILE_ASSERT’ #define COMPILE_ASSERT(exp, name) static_assert((exp), #name) ^ ./Source/JavaScriptCore/jit/GPRInfo.h:772:34: error: ‘GPRInfo’ has not been declared COMPILE_ASSERT(GPRInfo::regT0 == GPRInfo::returnValueGPR, regT0_must_equal_returnValueGPR); ^ ./Source/WTF/wtf/Assertions.h:325:50: note: in definition of macro ‘COMPILE_ASSERT’ #define COMPILE_ASSERT(exp, name) static_assert((exp), #name) ^ ./Source/JavaScriptCore/jit/GPRInfo.h:774:16: error: ‘GPRInfo’ has not been declared COMPILE_ASSERT(GPRInfo::regT1 == GPRInfo::returnValueGPR2, regT1_must_equal_returnValueGPR2); ^ ./Source/WTF/wtf/Assertions.h:325:50: note: in definition of macro ‘COMPILE_ASSERT’ #define COMPILE_ASSERT(exp, name) static_assert((exp), #name) ^ ./Source/JavaScriptCore/jit/GPRInfo.h:774:34: error: ‘GPRInfo’ has not been declared COMPILE_ASSERT(GPRInfo::regT1 == GPRInfo::returnValueGPR2, regT1_must_equal_returnValueGPR2); ^ ./Source/WTF/wtf/Assertions.h:325:50: note: in definition of macro ‘COMPILE_ASSERT’ #define COMPILE_ASSERT(exp, name) static_assert((exp), #name) ^ make: *** [Source/JavaScriptCore/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o] Error 1
Emilio Pozuelo Monfort
Comment 4 2013-11-23 03:43:38 PST
Mark Lam
Comment 5 2013-11-23 11:00:46 PST
Created attachment 217751 [details] the patch.
EFL EWS Bot
Comment 6 2013-11-23 11:15:18 PST
Geoffrey Garen
Comment 7 2013-11-23 11:34:53 PST
Comment on attachment 217751 [details] the patch. r=me
Build Bot
Comment 8 2013-11-23 11:43:19 PST
EFL EWS Bot
Comment 9 2013-11-23 12:07:32 PST
Comment on attachment 217751 [details] the patch. Attachment 217751 [details] did not pass efl-wk2-ews (efl-wk2): Output: http://webkit-queues.appspot.com/results/34998074
Filip Pizlo
Comment 10 2013-11-23 12:24:31 PST
I think that this is the wrong approach. tryToDisassemble should be defined even if !ENABLE(JIT). This would allow you to get rid of some of these #if's. In the future when these bugs arise I think it's better to add stubs for !ENABLE(JIT) than to start splattering #if's all over the codebase.
kov's GTK+ EWS bot
Comment 11 2013-11-23 13:31:31 PST
Iain Lane
Comment 12 2013-11-25 02:52:00 PST
Gets further with this, but eventually hits libtool: link: g++-4.8 -pthread -std=c++11 -Wno-c++11-compat -O2 -D_FORTIFY_SOURCE=2 -Wl,-z -Wl,relro -Wl,--no-keep-memory -Wl,--no-demangle -o Programs/LLIntOffsetsExtractor Source/JavaScriptCore/llint/Programs_LLIntOffsetsExtractor-LLIntOffsetsExtractor.o -Wl,--export-dynamic -pthread ./.libs/libWTF.a -lz -licui18n -licuuc -licudata -lgmodule-2.0 -lgthread-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -lpthread -lstdc++ -pthread /usr/bin/ruby ./Source/JavaScriptCore/offlineasm/asm.rb ./Source/JavaScriptCore/llint/LowLevelInterpreter.asm Programs/LLIntOffsetsExtractor DerivedSources/JavaScriptCore/LLIntAssembly.h offlineasm: Parsing ./Source/JavaScriptCore/llint/LowLevelInterpreter.asm and Programs/LLIntOffsetsExtractor and creating assembly file DerivedSources/JavaScriptCore/LLIntAssembly.h. offlineasm: Including file ./Source/JavaScriptCore/llint/LowLevelInterpreter64.asm offlineasm: Including file ./Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:393:in `validate': Unresolved extraStackSpace at ./Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:91 (RuntimeError) from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:399:in `block in validateChildren' from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:397:in `each' from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:397:in `validateChildren' from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:456:in `validate' from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:399:in `block in validateChildren' from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:397:in `each' from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:397:in `validateChildren' from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/transform.rb:406:in `validate' from ./Source/JavaScriptCore/offlineasm/asm.rb:268:in `block (3 levels) in <main>' from /home/laney/WebKit/Source/JavaScriptCore/offlineasm/settings.rb:89:in `forSettings' from ./Source/JavaScriptCore/offlineasm/asm.rb:265:in `block (2 levels) in <main>' from ./Source/JavaScriptCore/offlineasm/asm.rb:261:in `each' from ./Source/JavaScriptCore/offlineasm/asm.rb:261:in `block in <main>' from ./Source/JavaScriptCore/offlineasm/asm.rb:252:in `open' from ./Source/JavaScriptCore/offlineasm/asm.rb:252:in `<main>' make: *** [DerivedSources/JavaScriptCore/LLIntAssembly.h] Error 1 That's when configuring like so: CPPFLAGS="-D_FORTIFY_SOURCE=2 -DENABLE_JIT=0 -DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0" LDFLAGS="-Wl,-z,relro -Wl,--no-keep-memory" CC="gcc-4.8" CXX="g++-4.8" ./configure --prefix=/usr --with-gtk=2.0 --disable-silent-rules --host=powerpc-linux-gnu --build=powerpc-linux-gnu --enable-gtk-doc --enable-introspection --enable-geolocation --disable-webkit2
Mark Lam
Comment 13 2013-12-02 12:02:34 PST
Created attachment 218206 [details] patch 2: Need to fix the build when disabling the DISASSEMBLER as well.
Mark Lam
Comment 14 2013-12-02 14:52:25 PST
Comment on attachment 218206 [details] patch 2: Need to fix the build when disabling the DISASSEMBLER as well. The EWS bots look good. Time for a review.
Geoffrey Garen
Comment 15 2013-12-02 17:22:46 PST
Comment on attachment 218206 [details] patch 2: Need to fix the build when disabling the DISASSEMBLER as well. r=me
Mark Lam
Comment 16 2013-12-02 17:31:05 PST
Tomas Popela
Comment 17 2013-12-05 02:46:31 PST
Should the proposed patch fix the issue mentioned in comment #12? If so I'm still getting it on ppc32 (ppc64 is working fine)..
Mark Lam
Comment 18 2013-12-05 02:57:32 PST
(In reply to comment #17) > Should the proposed patch fix the issue mentioned in comment #12? If so I'm still getting it on ppc32 (ppc64 is working fine).. It builds fine for me. Can you confirm that you are building with ENABLE_LLINT_C_LOOP set to 1?
Iain Lane
Comment 19 2013-12-05 04:35:25 PST
(In reply to comment #18) > (In reply to comment #17) > > Should the proposed patch fix the issue mentioned in comment #12? If so I'm still getting it on ppc32 (ppc64 is working fine).. > > It builds fine for me. Can you confirm that you are building with ENABLE_LLINT_C_LOOP set to 1? I think that's forced on by disabling ENABLE_JIT, isn't it?
Mark Lam
Comment 20 2013-12-05 04:37:27 PST
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > Should the proposed patch fix the issue mentioned in comment #12? If so I'm still getting it on ppc32 (ppc64 is working fine).. > > > > It builds fine for me. Can you confirm that you are building with ENABLE_LLINT_C_LOOP set to 1? > > I think that's forced on by disabling ENABLE_JIT, isn't it? Yes, but I didn't know if Tomas' build environment has customizations that changes that or not, and I didn't want to assume. So, I asked for the verification.
Tomas Popela
Comment 21 2013-12-05 05:01:41 PST
Actually I was compiling the WebKitGTK+ 2.3.2 (snapshot of WebKit trunk ~ 2 weeks ago) and I applied patches from Mark but I intentionally missed this one https://bugs.webkit.org/show_bug.cgi?id=125186 (as I'm not compiling on Win) but that patch was what I missed. So sorry about that, it's compiling successfully now.
Iain Lane
Comment 22 2013-12-05 05:16:34 PST
(In reply to comment #21) > Actually I was compiling the WebKitGTK+ 2.3.2 (snapshot of WebKit trunk ~ 2 weeks ago) and I applied patches from Mark but I intentionally missed this one https://bugs.webkit.org/show_bug.cgi?id=125186 (as I'm not compiling on Win) but that patch was what I missed. So sorry about that, it's compiling successfully now. Ah, thanks; trying that myself now (last tried trunk when I posted the failure, which was before this change).
Note You need to log in before you can comment on or make changes to this bug.