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?
Created attachment 170130 [details] test1
Created attachment 170131 [details] test2
Created attachment 170132 [details] patch1
Created attachment 170133 [details] patch2
If you are submitting a patch for inclusion in WebKit, please follow the steps from <http://www.webkit.org/coding/contributing.html>.
>If you are submitting a patch for inclusion in WebKit, please follow the steps from <http://www.webkit.org/coding/contributing.html>. These patches were for explanation, not for contributing. Now the main problem with JSC catching SIGILL on ARMv7 is fixed, since svn revision http://trac.webkit.org/changeset/133357 , but while running JSC-debug-version asserts commented in patch1 still fail on both of introduced tests. Can anybody explain, why we have to randomize JIT assembly code this way https://bugs.webkit.org/show_bug.cgi?id=61161 ?
This is too old to be actionable.