[Webkit-unassigned] [Bug 239036] New: WebKit-GTK 2.36.0 fails to build with Webassembly/JIT disabled

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=239036

            Bug ID: 239036
           Summary: WebKit-GTK 2.36.0 fails to build with Webassembly/JIT
                    disabled
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: dave at killthe.net

This is in relation to another bug which I have not filed because at this time I don't have any kind of usable backtrace, or knowledge of how to generate one. That bug started when I moved my hard drive with existing Linux install from an AMD Ryzen system to an older AMD desktop, because the CPU is apparently going bad in the former. Everything continued to work flawlessly, except for WebKit, which started crashing on a certain web site. After compiling a debug build and connecting to WebKitWebProcess with gdb to observe the crash, it was triggering a SIGILL "Illegal Instruction" exception.

The backtrace was totally worthless as it was just a long string of memory addresses with no function names, and after looking up one of the functions that was actually named, it appears the crash may be in code that was generated by JIT--which makes sense as it appears to be triggered when certain Javascript on the page executes. 

So I tried to compile a version of WebKit with webassembly disabled, to hopefully work around the bug as I need this browser working ASAP. I did this by patching ./Source/cmake/WebKitFeatures.cmake to set the default WebAssembly/JIT options under "if (WTF_CPU_ARM64 OR WTF_CPU_X86_64)" to be the same as in the final "else" clause down at the bottom, which would be used in the event of a 32-bit compile; i.e. JIT disabled and C-LOOP enabled. 

With this setting, now there is an error with missing symbols when linking JavaScriptCore. Specifically the (worthless) output from Gold linker:

/usr/bin/ld: /sources/stage4/webkitgtk-2.36.0/build/lib/libjavascriptcoregtk-4.1.so: undefined reference to `JSC::JSCell::inherits(JSC::VM&, JSC::ClassInfo const*) const'
/usr/bin/ld: /sources/stage4/webkitgtk-2.36.0/build/lib/libjavascriptcoregtk-4.1.so: undefined reference to `JSC::HeapCell::vm() const'
/usr/bin/ld: /sources/stage4/webkitgtk-2.36.0/build/lib/libjavascriptcoregtk-4.1.so: undefined reference to `JSC::JSCell::structure() const'
collect2: error: ld returned 1 exit status

The output from BFD linker is much more detailed, showing exact source files etc, but is almost impossible for me to decipher as the problem seems to be some kind of macro/template issue that isn't at all obvious.

Now at this point if you'll permit me to rant: EVERY TIME I upgrade to a new WebKit version, it never is a smooth process. NEVER. It always involves hours of compiling mixed with writing numerous patches to fix compile errors which are caused by my configuration being not exactly the same config as you use in house. It's almost like you NEVER test compile WebKit in different configurations before shipping it out. 

2.36.0 has actually been better than usual in this regard, but so far I've had to write three patches just to get it to compile a) in debug mode; b) with accessibility disabled, because I don't use dbus; and now a patch in process, c) to fix building with WebAssembly/JIT disabled. (See attachments in comments below.) I've hit a stumbling block on that last patch due to this crazy missing symbol error which I'm at my wits' end trying to figure out. 

Could you PLEASE expand your testing of WebKit under various build configurations before shipping it out the door, so the end user doesn't have to apply 3-5+ different, ever changing patches each upgrade cycle just to get it to build in non-default configuration? I don't understand this huge, complicated code base well enough to always be having to write patches just to do something that should be easy and simple, like building with JIT disabled. And in the mean time my WebKit browser is useless until I can somehow get this problem figured out! Infuriating.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220409/093eaa69/attachment.htm>