[Webkit-unassigned] [Bug 100111] New: JSC SIGILL, problems with lower bit on ARMv7-thumb

[bugzilla-daemon at webkit.org]

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

           Summary: JSC SIGILL, problems with lower bit on ARMv7-thumb
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zhroma at ispras.ru


Here I want to discuss problems I have found in JSC with lower bit on ARMv7-Thumb. Both of my test scripts are small cut versions which help to reproduce the problem. I cross-compile JSC from x86-64 in two modes — with gcc "-mthumb -O0" options in debug mode (debug-jsc), and with gcc "-mthumb -O2" options in release mode (release-jsc). Then I run my tests on ARM using command-line jsc program.

First of all, since I start testing JSC on ARMv7-Thumb, the test1 example fails debug-jsc:
ASSERTION FAILED: reinterpret_cast<intptr_t>(m_value) & 1
Source/JavaScriptCore/assembler/MacroAssemblerCodeRef.h(106) : JSC::FunctionPtr::FunctionPtr(returnType (*)(argType1)) [with returnType = int; argType1 = double]
This failure doesn't give any problems — the release-jsc version works fine.
So, I just commented two asserts which were broken — patch1.
This problem exist at least since svn revision 129000, and maybe it was introduced much earlier.

The next problem happens exaclty since svn revision 130826 (or 130828, because in revisions 130826-130827 the build was broken).
If I build debug-jsc with patch1 the test1 works fine, but the test2 example fails with another assertion:
ASSERTION FAILED: !(reinterpret_cast<intptr_t>(target) & 1)
../srcpeakd/Source/JavaScriptCore/assembler/ARMv7Assembler.h(2559) : static void JSC::ARMv7Assembler::linkJumpAbsolute(uint16_t*, void*)
Here I tried the same, just commented all "wrong" asserts - patch2. As a result I can run the test, but sometimes (in 50% cases) it fails with "Illegal instruction" or "Segmentation fault". The same failure happens when running release-jsc version. When I run the test 15 times successively, it fails at least 3 times or more. Using the debugger I understand that this happens when baselineJIT-generated code is executed. Code (assembly) is fine, but the program counter gets the wrong position in it. So, the problem is maybe in wrong processor mode (arm vs thumb) controlled by the lower bit.

And the last. While investigating the previous problem, I find some code introduced by the patch from https://bugs.webkit.org/show_bug.cgi?id=61161. There is no explaination why JSC needs such a randomization, and maybe additional nop creation should be at least disabled in debug mode?

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