[Webkit-unassigned] [Bug 96286] Another SIGILL in JavaScriptCore on a Geode processor

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Filip Pizlo <fpizlo at apple.com>  2012-09-28 12:31:00 PST ---
(In reply to comment #1)
> Oliver, you rescued us last time, can you help us here? :)
> 
> I have checked the basics from bug #82496: isSSE2Present() still returns false on this platform (cpuid feature bits does not suggest that SSE2 is supported), DFG canCompileOpcodes() still calls down to MacroAssembler::supportsFloatingPoint() which correctly says "no".
> 
> Searching through the source for e.g. mulsd, I see two potential places where mulsd instructions might be generated which aren't directly/obviously protected by the above checks. They are:
>  1. ./Source/JavaScriptCore/assembler/X86Assembler.h (mulsd_mr) ?
>  2. ./Source/JavaScriptCore/offlineasm/x86.rb
> 
> I guess offlineasm has a likelihood of being the culprit, given that this is a regression over webkitgtk-1.8 and offlineasm/LLint seems to be a new feature. CCing  Filip Pizlo who seems to be involved in this project. Filip, sorry to bother you, would you mind checking if llint/offlineasm checks that the x86 CPU supports SSE2 instructions before executing them? Or point us to a better candidate to ask?

No, it does no such checks.

I think you have three approaches to fixing this:

1) Switch GTK to either LLInt cloop-only or JIT-only.

2) Add support in the offlineasm x86 backend to compile floating point primitives to x87.  Then have a build flag indicating that you intend to target no-SSE configurations, and in those configurations, have offlineasm use x87 instead of SSE2.

3) Use run-time checks in LLInt:

a) Transform that hasSSE2() run-time check into something that sets a flag on JSGlobalData.  Rename it to hasFloatingPoint().  We will never support x87 floating point unless you implement it, so a chip that doesn't have SSE2 amounts to a chip that doesn't have floating point.

b) Add a MAY_NOT_HAVE_FLOATING_POINT flag somewhere, and plumb it through to the LLInt.  This is similar to the flag you'll need for (2) above.

3) If MAY_NOT_HAVE_FLOATING_POINT is true, then the LLInt should do an extra check prior at the top of floating point paths checking if JSGlobalData::hasFloatingPoint is false; if it's false then jump straight to the slow path.

Those are your options.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.