Full Text Bug Listing

Landry Breuil

Reported 2013-03-30 03:06:26 PDT

As of now on those archs, build fails with : rce/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp' || echo './'`Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp In file included from ./Source/JavaScriptCore/bytecode/ValueRecovery.h:31, from ./Source/JavaScriptCore/bytecode/CodeOrigin.h:31, from ./Source/JavaScriptCore/bytecode/CodeBlock.h:39, from Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:29: ./Source/JavaScriptCore/assembler/MacroAssembler.h:62:2: error: #error "The MacroAssembler is not supported on this platform." In file included from /usr/include/g++/iosfwd:45, from /usr/include/g++/bits/stl_algobase.h:70, from /usr/include/g++/algorithm:65, from ./Source/WTF/wtf/Alignment.h:25, from ./Source/WTF/wtf/HashTable.h:25, from ./Source/WTF/wtf/HashMap.h:24, from ./Source/JavaScriptCore/runtime/JSCJSValue.h:31, from ./Source/JavaScriptCore/heap/HandleTypes.h:29, from ./Source/JavaScriptCore/runtime/WriteBarrier.h:30, from ./Source/JavaScriptCore/runtime/PropertyStorage.h:29, from ./Source/JavaScriptCore/runtime/IndexingHeader.h:29, from ./Source/JavaScriptCore/runtime/ArrayConventions.h:24, from ./Source/JavaScriptCore/runtime/JSArray.h:24, from ./Source/JavaScriptCore/bytecode/ArrayProfile.h:29, from Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28: /usr/include/g++/powerpc-unknown-openbsd5.3/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, const char*, ...)': /usr/include/g++/powerpc-unknown-openbsd5.3/bits/c++locale.h:81: warning: function might be possible candidate for 'printf' format attribut e In file included from ./Source/JavaScriptCore/bytecode/ValueRecovery.h:31, from ./Source/JavaScriptCore/bytecode/CodeOrigin.h:31, from ./Source/JavaScriptCore/bytecode/CodeBlock.h:39, from Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:29: ./Source/JavaScriptCore/assembler/MacroAssembler.h: At global scope: ./Source/JavaScriptCore/assembler/MacroAssembler.h:67: error: expected class-name before '{' token ./Source/JavaScriptCore/assembler/MacroAssembler.h:70: error: 'MacroAssemblerBase' has not been declared ./Source/JavaScriptCore/assembler/MacroAssembler.h:71: error: 'MacroAssemblerBase' has not been declared ./Source/JavaScriptCore/assembler/MacroAssembler.h:72: error: 'MacroAssemblerBase' has not been declared ./Source/JavaScriptCore/assembler/MacroAssembler.h:73: error: 'MacroAssemblerBase' has not been declared ./Source/JavaScriptCore/assembler/MacroAssembler.h:161: error: 'RegisterID' has not been declared ./Source/JavaScriptCore/assembler/MacroAssembler.h:166: error: 'Address' does not name a type ./Source/JavaScriptCore/assembler/MacroAssembler.h:171: error: 'RegisterID' has not been declared ./Source/JavaScriptCore/assembler/MacroAssembler.h:176: error: 'TrustedImm32' has not been declared etc etc etc.. If i force-disable assembler/yarr jit with JSC_CPPFLAGS="-DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0" in the build env, it fails with : ./Source/WTF/wtf/MathExtras.h: In function 'bool std::signbit(double)': ./Source/WTF/wtf/MathExtras.h:112: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from Source/JavaScriptCore/llint/LowLevelInterpreter.cpp:406: ./DerivedSources/JavaScriptCore/LLIntAssembly.h: In static member function 'static JSC::JSValue JSC::LLInt::CLoop::execute(JSC: :CallFrame*, JSC::OpcodeID, bool)': ./DerivedSources/JavaScriptCore/LLIntAssembly.h:2545: error: 'isnan' was not declared in this scope ./DerivedSources/JavaScriptCore/LLIntAssembly.h:2548: error: 'Double2Ints' was not declared in this scope ./DerivedSources/JavaScriptCore/LLIntAssembly.h:2834: error: 'isnan' was not declared in this scope ./DerivedSources/JavaScriptCore/LLIntAssembly.h:4736: error: 'isnan' was not declared in this scope Help welcome. I suppose the logic for ENABLE_ASSEMBLER in Source/WTF/wtf/Platform.h is somewhat broken for those archs.

Landry Breuil

Comment 1 2013-03-30 07:33:54 PDT

Some more notes on this - the first problem of ENABLE_ASSEMBLER left out, the second issue can be worked around this way : Backport http://trac.webkit.org/changeset/145551 -> Fixes the 'error: 'Double2Ints' was not declared in this scope' Fix Source/JavaScriptCore/offlineasm/cloop.rb so that it only spits std::isnan and not std::isnan || isnan fixes the 'error: 'isnan' was not declared in this scope' --- Source/JavaScriptCore/offlineasm/cloop.rb.orig Tue Feb 19 08:44:37 2013 +++ Source/JavaScriptCore/offlineasm/cloop.rb Sat Mar 30 13:06:32 2013 @@ -398,7 +398,7 @@ def cloopEmitUnaryOperation(operands, type, operator) end def cloopEmitCompareDoubleWithNaNCheckAndBranch(operands, condition) - $asm.putc "if (std::isnan(#{operands[0].clValue(:double)}) || isnan(#{operands[1].clValue(:double)})" + $asm.putc "if (std::isnan(#{operands[0].clValue(:double)})" $asm.putc " || (#{operands[0].clValue(:double)} #{condition} #{operands[1].clValue(:double)}))" $asm.putc " goto #{operands[2].cLabel};" end On OpenBSD (don't know for the others), including <cmath> to reach std::isnan() #undefs isnan, and because of multiple inclusion protection including math.h again afterwards doesn't get isnan() defined back, so both cant be used at the same time.

Landry Breuil

Comment 2 2013-03-31 01:41:46 PDT

Using all the aforementioned changes (disable asm/yarr in env, backport r145551, fix cloop.rb wrt isnan) , i managed to get webkitgtk 1.11.91 to build on OpenBSD/ppc. Will try 2.0.0. Unfortunately runtime seems broken: GtkLauncher just spits '** Message: console message: undefined @0: RangeError: Maximum call stack size exceeded.', and midori crashes with what seems an infinite recursion in CLoop::execute : (gdb) bt #0 0x8e95a0d4 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 #1 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 #2 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 #3 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 Any guidance in where to look; which commits to backport, or what 'sort-of-related bug report' to see is welcome.

Landry Breuil

Comment 3 2013-03-31 02:01:46 PDT

Thinking out loud, maybe #103128 would fix ppc 32 bits ?

Filip Pizlo

Comment 4 2013-03-31 21:58:38 PDT

(In reply to comment #2) > Using all the aforementioned changes (disable asm/yarr in env, backport r145551, fix cloop.rb wrt isnan) , i managed to get webkitgtk 1.11.91 to build on OpenBSD/ppc. Will try 2.0.0. > > Unfortunately runtime seems broken: GtkLauncher just spits '** Message: console message: undefined @0: RangeError: Maximum call stack size exceeded.', and midori crashes with what seems an infinite recursion in CLoop::execute : > > (gdb) bt > #0 0x8e95a0d4 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 > #1 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 > #2 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 > #3 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 > > Any guidance in where to look; which commits to backport, or what 'sort-of-related bug report' to see is welcome. I would love to help but I don't have a big-endian 64-bit machine. Can you enable LLINT_EXECUTION_TRACING (LLIntCommon.h) and try to run some of the basic tests? Like run-javascriptcore-tests? Or attempt to run GtkLauncher and see what happens?

Landry Breuil

Comment 5 2013-04-01 12:48:17 PDT

as i said in #103128 ( sorry for being on both sides.. ), using a modified patchset from that bug 'fixes' the infinite loop, but runtime still seems broken. I'll try LLINT_EXECUTION_TRACING. Some questions : am i right that ENABLE_ASSEMBLER and ENABLE_YARR_JIT should _not_ be set on ppc/mips64el/sparc64 ? Is there a way to only build the js shell from a webkitgtk-2.0.0 src tarball, without spending 24h building the whole thing ? gmake jsc-1 should do the trick ?

Dan Horák

Comment 6 2013-04-02 04:21:39 PDT

(In reply to comment #4) > (In reply to comment #2) > > Using all the aforementioned changes (disable asm/yarr in env, backport r145551, fix cloop.rb wrt isnan) , i managed to get webkitgtk 1.11.91 to build on OpenBSD/ppc. Will try 2.0.0. > > > > Unfortunately runtime seems broken: GtkLauncher just spits '** Message: console message: undefined @0: RangeError: Maximum call stack size exceeded.', and midori crashes with what seems an infinite recursion in CLoop::execute : > > > > (gdb) bt > > #0 0x8e95a0d4 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 > > #1 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 > > #2 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 > > #3 0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0 > > > > Any guidance in where to look; which commits to backport, or what 'sort-of-related bug report' to see is welcome. > > I would love to help but I don't have a big-endian 64-bit machine. this problem can most likely be solved, I'll come to you with the details when I'll have them

Landry Breuil

Comment 7 2013-04-02 09:22:22 PDT

Building with LLINT_EXECUTION_TRACING defined to 1 in LLIntCommon.h doesnt seem to make jsc more verbose. Maybe i'm missing something ?

Emilio Pozuelo Monfort

Comment 8 2013-08-31 04:31:07 PDT

(In reply to comment #0) > If i force-disable assembler/yarr jit with JSC_CPPFLAGS="-DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0" in the build env, it fails with : This is no longer possible in 2.1.x after the change from bug #119445. CPPFLAGS should be fine though. The arches that don't support this stuff should define ENABLE_JIT, ENABLE_YARR_JIT and ENABLE_ASSEMBLER to 0 in Source/WTF/wtf/Platform.h The problem seems to be that YARR_JIT and ASSEMBLER are enabled if one of JIT or LLINT_C_LOOP are enabled: /* Yet Another Regex Runtime - turned on by default for JIT enabled ports. */ #if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT)) #define ENABLE_YARR_JIT 1 But LLINT_C_LOOP is enabled if JIT is disabled, so the above check is always true: /* If the jit is not available, enable the LLInt C Loop: */ #if !ENABLE(JIT) #undef ENABLE_LLINT /* Undef so that we can redefine it. */ #undef ENABLE_LLINT_C_LOOP /* Undef so that we can redefine it. */ #undef ENABLE_DFG_JIT /* Undef so that we can redefine it. */ #define ENABLE_LLINT 1 #define ENABLE_LLINT_C_LOOP 1 #define ENABLE_DFG_JIT 0 #endif

Landry Breuil

Comment 9 2013-10-06 05:39:41 PDT

(In reply to comment #8) > (In reply to comment #0) > > If i force-disable assembler/yarr jit with JSC_CPPFLAGS="-DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0" in the build env, it fails with : > > This is no longer possible in 2.1.x after the change from bug #119445. CPPFLAGS should be fine though. > > The arches that don't support this stuff should define ENABLE_JIT, ENABLE_YARR_JIT and ENABLE_ASSEMBLER to 0 in Source/WTF/wtf/Platform.h > > The problem seems to be that YARR_JIT and ASSEMBLER are enabled if one of JIT or LLINT_C_LOOP are enabled: > > /* Yet Another Regex Runtime - turned on by default for JIT enabled ports. */ > #if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT)) > #define ENABLE_YARR_JIT 1 > > But LLINT_C_LOOP is enabled if JIT is disabled, so the above check is always true: > > /* If the jit is not available, enable the LLInt C Loop: */ > #if !ENABLE(JIT) > #undef ENABLE_LLINT /* Undef so that we can redefine it. */ > #undef ENABLE_LLINT_C_LOOP /* Undef so that we can redefine it. */ > #undef ENABLE_DFG_JIT /* Undef so that we can redefine it. */ > #define ENABLE_LLINT 1 > #define ENABLE_LLINT_C_LOOP 1 > #define ENABLE_DFG_JIT 0 > #endif Fwiw, here's what i've ended up to fix the build : /* Yet Another Regex Runtime - turned on by default for JIT enabled ports. */ -#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT)) +#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT)) && !(OS(QNX) && PLATFORM(QT)) #define ENABLE_YARR_JIT 1 /* Setting this flag compares JIT results with interpreter results. */ @@ -863,7 +874,7 @@ /* If either the JIT or the RegExp JIT is enabled, then the Assembler must be enabled as well: */ -#if ENABLE(JIT) || ENABLE(YARR_JIT) +#if ENABLE(JIT) #if defined(ENABLE_ASSEMBLER) && !ENABLE_ASSEMBLER #error "Cannot enable the JIT or RegExp JIT without enabling the Assembler" #else

Thomas De Schampheleire

Comment 10 2013-11-13 08:16:46 PST

(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #0) [..] > > Fwiw, here's what i've ended up to fix the build : > > /* Yet Another Regex Runtime - turned on by default for JIT enabled ports. */ > -#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT)) > +#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT)) && !(OS(QNX) && PLATFORM(QT)) > #define ENABLE_YARR_JIT 1 For most cases this will still set YARR_JIT to 1, because the last clause is almost always true: not QNX and QT. Instead, I have been trying the following change (on a different version): -#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT)) +#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) && !(OS(QNX) && PLATFORM(QT))) (so moving the platform check together with JIT, meaning that if JIT is not enabled, YARR JIT won't be either). I'm not 100% sure if this is correct, as I'm in no way a webkit expert. > > /* Setting this flag compares JIT results with interpreter results. */ > @@ -863,7 +874,7 @@ > > /* If either the JIT or the RegExp JIT is enabled, then the Assembler must be > enabled as well: */ > -#if ENABLE(JIT) || ENABLE(YARR_JIT) > +#if ENABLE(JIT) > #if defined(ENABLE_ASSEMBLER) && !ENABLE_ASSEMBLER > #error "Cannot enable the JIT or RegExp JIT without enabling the Assembler" > #else This does not seem correct. It makes sense that you need the assembler for all types of JIT (both JIT as YARR_JIT). With the mentioned change in Platform.h, and the Double2Ints fix from comment #1, I can compile much further (I'm building webkit 1.11.5 for a 32-bit powerpc target). However, eventually I get a link problem, but I don't know if it's related to the above problem: ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::tag() const' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::decode(long long)' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::payload() const' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::asCell() const' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::JSValue(int, int)' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::JSValue()' collect2: ld returned 1 exit status ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::tag() const' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::decode(long long)' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::payload() const' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::asCell() const' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::JSValue(int, int)' ./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::JSValue()' collect2: ld returned 1 exit status make[2]: *** [Programs/jsc-1] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [Programs/minidom] Error 1 make[2]: Leaving directory `/home/tdescham/repo/contrib/buildroot-webkit/output/build/webkit-1.11.5' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/tdescham/repo/contrib/buildroot-webkit/output/build/webkit-1.11.5'

YunQiang Su

Comment 11 2013-11-14 05:17:16 PST

Created attachment 216925 [details] patches for mips64el build, workable for Debian GNU/Linux With this patch, I can build webkitgtk 2.2.0 on Debian for MIPS64EL/Linux

Landry Breuil

Comment 12 2013-11-14 05:33:26 PST

(In reply to comment #11) > Created an attachment (id=216925) [details] > patches for mips64el build, workable for Debian GNU/Linux > > With this patch, I can build webkitgtk 2.2.0 on Debian for MIPS64EL/Linux But does it actually run ?

Emilio Pozuelo Monfort

Comment 13 2013-11-14 07:09:05 PST

(In reply to comment #11) > Created an attachment (id=216925) [details] > patches for mips64el build, workable for Debian GNU/Linux > > With this patch, I can build webkitgtk 2.2.0 on Debian for MIPS64EL/Linux That's unrelated, please open a new bug to add MIPS64 support.

Thomas De Schampheleire

Comment 14 2013-11-19 04:26:49 PST

(In reply to comment #10) Any feedback on these findings?

Aaron Bamberger

Comment 15 2015-08-20 10:41:58 PDT

(In reply to comment #14) > (In reply to comment #10) > > Any feedback on these findings? I realize this is years later, but I've run into the same problem and was able to get webkitgtk to build with the JIT disabled by using both the patch from comment #1, and by using the patch in comment #56 on this bug: https://bugs.webkit.org/show_bug.cgi?id=105696 Changeset: http://trac.webkit.org/changeset/142489 to fix the linker errors mentioned in comment #14

Attachments
patches for mips64el build, workable for Debian GNU/Linux (2.70 KB, patch) 2013-11-14 05:17 PST, YunQiang Su	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Bug 113638