Created attachment 418216 [details] Provide an alternative implementation for rounding if the SSE4 rounding instructions are not available The JIT uses SSE4 instructions (rounding instructions) which are not available on SSE4a, which yields an "illegal instruction". The attached patch provides an alternative implementation when these rounding instructions are not available, tested with cpu0: "AMD Athlon(tm) II X3 450 Processor" cpu0: AMD Family 10h (686-class), 3200.11 MHz cpu0: family 0x10 model 0x5 stepping 0x3 (id 0x100f53) cpu0: features 0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE> cpu0: features 0x178bfbff<MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> cpu0: features1 0x802009<SSE3,MONITOR,CX16,POPCNT> cpu0: features2 0xefd3fbff<SYSCALL/SYSRET,NOX,MMXX,MMX,FXSR,FFXSR,P1GB,RDTSCP> cpu0: features2 0xefd3fbff<LONG,3DNOW2,3DNOW> cpu0: features3 0x37ff<LAHF,CMPLEGACY,SVM,EAPIC,ALTMOVCR0,LZCNT,SSE4A> cpu0: features3 0x37ff<MISALIGNSSE,3DNOWPREFETCH,OSVW,IBS,SKINIT,WDT> on https://binji.github.io/raw-wasm/doomfire
Created attachment 418217 [details] A patch for the offlineasm part (incomplete, needs feature test) This patch is similar to the JIT patch, but I could not find the feature test for rounding. So the patch is incomplete until the feature test is added.
<rdar://problem/73686509>
Since precision of x87 and SSE are different, we should not mix both. So, 1. In LLInt, let's just use slow path function calls instead in x64. 2. In Wasm Air tier, we should emit function call nodes instead of using CeilDouble etc. if supportsFloatingPointRounding() returns false. 3. In Wasm OMG tier, we do not need to do anything since B3::Ceil etc. is automatically converted into function calls if supportsFloatingPointRounding is false. Could you upload a patch with webkit-patch? We need ChangeLog update where we need very descriptive explanation about the change.
Apologies for taking so very long to reply. Would you like me to upload the (incorrect) patch? Unfortunately my hardware stopped working, so I cannot test the patch on real hardware anymore and I am not sure what the best way is to proceed (I guess very few people still have these CPUs).
*** Bug 222805 has been marked as a duplicate of this bug. ***
We have an affected user in #epiphany:gnome.org who would no doubt be happy to test an updated patch (or -- better -- a pull request) for this issue, should somebody decide to provide one.
Indeed I do have access to such hardware for testing* because my parents have a desktop computer running Fedora 38 with an AMD Phenom™ 9600B quad-core processor that otherwise runs pretty well. Wikipedia tells me the AMD Phenom II series also have this same sort of limitation. While testing, I was able to confirm that running with "JavaScriptCoreUseJIT=0" avoided the crash. To reproduce on my end (with those CPUs), with WebKitGtk's "MiniBrowser" or with Epiphany, it's as simple as clicking on any link to a PDF file on the web; as the browsers will try to open it with the built-in pdf.js viewer by default, it will trigger a crash 100% of the time because it tries to use "roundsd". A side-effect of such crashes is that the system can then become unresponsive because preinstalled tools like systemd-coredump automatically try to catch, compress and store (and possibly further process) the crashes every time, which can lead to a lot of I/O, CPU and disk usage, and overall lack of responsiveness of the system while the user is trying to use it, and it's not immediately obvious that it crashed behind the scenes. *: presuming I can use some sort of prebuilt package to test ideally, because I don't think I would be able to compile WebKit by myself on that machine with 4 GB of RAM ;)