Bug 113638 - webkitgtk 2.0.0 fails to build on OpenBSD (and maybe others) powerpc/mips64el/sparc64
: webkitgtk 2.0.0 fails to build on OpenBSD (and maybe others) powerpc/mips64el...
Status: UNCONFIRMED
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore
: 528+ (Nightly build)
: Unspecified Other
: P2 Normal
Assigned To: Nobody
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-30 03:06 PDT by Landry Breuil
Modified: 2014-10-30 21:41 PDT (History)
9 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Landry Breuil 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.
Comment 1 Landry Breuil 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.
Comment 2 Landry Breuil 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.
Comment 3 Landry Breuil 2013-03-31 02:01:46 PDT
Thinking out loud, maybe  #103128 would fix ppc 32 bits ?
Comment 4 Filip Pizlo 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?
Comment 5 Landry Breuil 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 ?
Comment 6 Dan Horák 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
Comment 7 Landry Breuil 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 ?
Comment 8 Emilio Pozuelo Monfort 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
Comment 9 Landry Breuil 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
Comment 10 Thomas De Schampheleire 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'
Comment 11 YunQiang Su 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
Comment 12 Landry Breuil 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 ?
Comment 13 Emilio Pozuelo Monfort 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.
Comment 14 Thomas De Schampheleire 2013-11-19 04:26:49 PST
(In reply to comment #10)

Any feedback on these findings?