113638 2013-03-30 03:06:26 -0700 webkitgtk 2.0.0 fails to build on OpenBSD (and maybe others) powerpc/mips64el/sparc64 2015-08-20 10:41:58 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Other UNCONFIRMED P2 Normal --- 0 landry webkit-unassigned aaron.bamberger changseok dan fpizlo gnome gustavo mrobinson patrickdepinguin pochu27 zan oldest_to_newest 866596 0 landry 2013-03-30 03:06:26 -0700 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. 866612 1 landry 2013-03-30 07:33:54 -0700 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. 866757 2 landry 2013-03-31 01:41:46 -0700 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. 866760 3 landry 2013-03-31 02:01:46 -0700 Thinking out loud, maybe #103128 would fix ppc 32 bits ? 866903 4 fpizlo 2013-03-31 21:58:38 -0700 (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? 867292 5 landry 2013-04-01 12:48:17 -0700 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 ? 867731 6 dan 2013-04-02 04:21:39 -0700 (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 867926 7 landry 2013-04-02 09:22:22 -0700 Building with LLINT_EXECUTION_TRACING defined to 1 in LLIntCommon.h doesnt seem to make jsc more verbose. Maybe i'm missing something ? 923271 8 pochu27 2013-08-31 04:31:07 -0700 (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 936764 9 landry 2013-10-06 05:39:41 -0700 (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 950169 10 patrickdepinguin 2013-11-13 08:16:46 -0800 (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' 950612 11 216925 wzssyqa 2013-11-14 05:17:16 -0800 Created attachment 216925 patches for mips64el build, workable for Debian GNU/Linux With this patch, I can build webkitgtk 2.2.0 on Debian for MIPS64EL/Linux 950617 12 landry 2013-11-14 05:33:26 -0800 (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 ? 950634 13 pochu27 2013-11-14 07:09:05 -0800 (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. 952027 14 patrickdepinguin 2013-11-19 04:26:49 -0800 (In reply to comment #10) Any feedback on these findings? 1119289 15 aaron.bamberger 2015-08-20 10:41:58 -0700 (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 216925 2013-11-14 05:17:16 -0800 2013-11-14 05:17:16 -0800 patches for mips64el build, workable for Debian GNU/Linux mips64-webkit.diff text/plain 2764 wzssyqa SW5kZXg6IHdlYmtpdGd0ay9Tb3VyY2UvV1RGL3d0Zi9QbGF0Zm9ybS5oCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHdlYmtpdGd0ay5vcmlnL1NvdXJjZS9XVEYvd3RmL1BsYXRmb3JtLmgJMjAxMy0xMC0yOSAxNzoz MjozOC4zNDkxMTY4NTggKzA4MDAKKysrIHdlYmtpdGd0ay9Tb3VyY2UvV1RGL3d0Zi9QbGF0Zm9y bS5oCTIwMTMtMTAtMjkgMTc6NDc6MTguNDU4NDgyMDQyICswODAwCkBAIC04OSwxMSArODksMTAg QEAKICNlbmRpZgogI2VuZGlmCiAKLS8qIENQVShNSVBTKSAtIE1JUFMgMzItYml0ICovCi0vKiBO b3RlOiBPbmx5IE8zMiBBQkkgaXMgdGVzdGVkLCBzbyB3ZSBlbmFibGUgaXQgZm9yIE8zMiBBQkkg Zm9yIG5vdy4gICovCi0jaWYgKGRlZmluZWQobWlwcykgfHwgZGVmaW5lZChfX21pcHNfXykgfHwg ZGVmaW5lZChNSVBTKSB8fCBkZWZpbmVkKF9NSVBTXykpIFwKLSAgICAmJiBkZWZpbmVkKF9BQklP MzIpCisvKiBDUFUoTUlQUykgLSBNSVBTIE8zMi9OMzIvTjY0ICovCisjaWYgKGRlZmluZWQobWlw cykgfHwgZGVmaW5lZChfX21pcHNfXykgfHwgZGVmaW5lZChNSVBTKSB8fCBkZWZpbmVkKF9NSVBT XykpCiAjZGVmaW5lIFdURl9DUFVfTUlQUyAxCisjaW5jbHVkZSA8c2dpZGVmcy5oPgogI2lmIGRl ZmluZWQoX19NSVBTRUJfXykKICNkZWZpbmUgV1RGX0NQVV9CSUdfRU5ESUFOIDEKICNlbmRpZgpA QCAtMTA3LDYgKzEwNiwyMyBAQAogI2RlZmluZSBXVEZfTUlQU19GUDY0IChkZWZpbmVkIF9fbWlw c19mcHIgJiYgX19taXBzX2ZwciA9PSA2NCkKIC8qIE1JUFMgcmVxdWlyZXMgYWxsb2NhdG9ycyB0 byB1c2UgYWxpZ25lZCBtZW1vcnkgKi8KICNkZWZpbmUgV1RGX1VTRV9BUkVOQV9BTExPQ19BTElH Tk1FTlRfSU5URUdFUiAxCisKKy8qIENQVShNSVBTNjQpIC0gTUlQUyA2NC1iaXQgYm90aCBCSUcg YW5kIExJVFRMRSBlbmRpYW4gKi8KKyNpZiBkZWZpbmVkKF9NSVBTX1NJTV9BQkk2NCkgJiYgKF9N SVBTX1NJTSA9PSBfTUlQU19TSU1fQUJJNjQpCisgICAjZGVmaW5lIFdURl9DUFVfTUlQUzY0IDEK KyAgICNkZWZpbmUgRU5BQkxFX0pJVCAwCisjZW5kaWYKKworLyogQ1BVKE1JUFNOMzIpIC0gTUlQ UyBOMzIgQUJJIGJvdGggQklHIGFuZCBMSVRUTEUgZW5kaWFuICovCisjaWYgZGVmaW5lZChfTUlQ U19TSU1fQUJJTjMyKSAmJiAoX01JUFNfU0lNID09IF9NSVBTX1NJTV9BQklOMzIpCisjZGVmaW5l IFdURl9DUFVfTUlQU04zMiAxCisjZW5kaWYKKworLyogQ1BVKE1JUFMzMikgLSBNSVBTIE8zMiBB QkkgYm90aCBCSUcgYW5kIExJVFRMRSBlbmRpYW4gKi8KKyNpZiBkZWZpbmVkKF9NSVBTX1NJTV9B QkkzMikgJiYgKF9NSVBTX1NJTSA9PSBfTUlQU19TSU1fQUJJMzIpCisjZGVmaW5lIFdURl9DUFVf TUlQUzMyIDEKKyNlbmRpZgorCiAjZW5kaWYgLyogTUlQUyAqLwogCiAvKiBDUFUoUFBDKSAtIFBv d2VyUEMgMzItYml0ICovCkBAIC02OTcsNyArNzEzLDggQEAKICAgICB8fCBDUFUoQUxQSEEpIFwK ICAgICB8fCBDUFUoU1BBUkM2NCkgXAogICAgIHx8IENQVShTMzkwWCkgXAotICAgIHx8IENQVShQ UEM2NCkKKyAgICB8fCBDUFUoUFBDNjQpIFwKKyAgICB8fCBDUFUoTUlQUzY0KQogI2RlZmluZSBX VEZfVVNFX0pTVkFMVUU2NCAxCiAjZWxzZQogI2RlZmluZSBXVEZfVVNFX0pTVkFMVUUzMl82NCAx CkBAIC03MjIsNyArNzM5LDcgQEAKIAogLyogVGhlIEpJVCBpcyBlbmFibGVkIGJ5IGRlZmF1bHQg b24gYWxsIHg4NiwgeDg2LTY0LCBBUk0gJiBNSVBTIHBsYXRmb3Jtcy4gKi8KICNpZiAhZGVmaW5l ZChFTkFCTEVfSklUKSBcCi0gICAgJiYgKENQVShYODYpIHx8IENQVShYODZfNjQpIHx8IENQVShB Uk0pIHx8IENQVShNSVBTKSkgXAorICAgICYmIChDUFUoWDg2KSB8fCBDUFUoWDg2XzY0KSB8fCBD UFUoQVJNKSB8fCBDUFUoTUlQUzMyKSkgXAogICAgICYmIChPUyhEQVJXSU4pIHx8ICFDT01QSUxF UihHQ0MpIHx8IEdDQ19WRVJTSU9OX0FUX0xFQVNUKDQsIDEsIDApKSBcCiAgICAgJiYgIU9TKFdJ TkNFKSBcCiAgICAgJiYgIShPUyhRTlgpICYmICFQTEFURk9STShRVCkpIC8qIFdlIHVzZSBKSVQg aW4gUU5YIFF0ICovCkBAIC03NjIsNyArNzc5LDcgQEAKICAgICAmJiBFTkFCTEUoSklUKSBcCiAg ICAgJiYgKE9TKERBUldJTikgfHwgT1MoTElOVVgpKSBcCiAgICAgJiYgKFBMQVRGT1JNKE1BQykg fHwgUExBVEZPUk0oSU9TKSB8fCBQTEFURk9STShHVEspIHx8IFBMQVRGT1JNKFFUKSkgXAotICAg ICYmIChDUFUoWDg2KSB8fCBDUFUoWDg2XzY0KSB8fCBDUFUoQVJNX1RIVU1CMikgfHwgQ1BVKEFS TV9UUkFESVRJT05BTCkgfHwgQ1BVKE1JUFMpIHx8IENQVShTSDQpKQorICAgICYmIChDUFUoWDg2 KSB8fCBDUFUoWDg2XzY0KSB8fCBDUFUoQVJNX1RIVU1CMikgfHwgQ1BVKEFSTV9UUkFESVRJT05B TCkgfHwgQ1BVKE1JUFMzMikgfHwgQ1BVKFNINCkpCiAjZGVmaW5lIEVOQUJMRV9MTElOVCAxCiAj ZW5kaWYKIApAQCAtNzc2LDcgKzc5Myw3IEBACiAjZGVmaW5lIEVOQUJMRV9ERkdfSklUIDEKICNl bmRpZgogLyogRW5hYmxlIHRoZSBERkcgSklUIG9uIEFSTSwgTUlQUyBhbmQgU0g0LiAqLwotI2lm IENQVShBUk1fVFJBRElUSU9OQUwpIHx8IENQVShNSVBTKSB8fCBDUFUoU0g0KQorI2lmIENQVShB Uk1fVFJBRElUSU9OQUwpIHx8IENQVShNSVBTMzIpIHx8IENQVShTSDQpCiAjZGVmaW5lIEVOQUJM RV9ERkdfSklUIDEKICNlbmRpZgogI2VuZGlmCg==