Bug 100111 - JSC SIGILL, problems with lower bit on ARMv7-thumb
Summary: JSC SIGILL, problems with lower bit on ARMv7-thumb
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other Linux
: P2 Normal
Assignee: Nobody
Depends on:
Blocks: 108645
  Show dependency treegraph
Reported: 2012-10-23 05:17 PDT by Roman Zhuykov
Modified: 2017-10-18 01:48 PDT (History)
3 users (show)

See Also:

test1 (232 bytes, application/javascript)
2012-10-23 05:18 PDT, Roman Zhuykov
no flags Details
test2 (898 bytes, application/javascript)
2012-10-23 05:19 PDT, Roman Zhuykov
no flags Details
patch1 (1.32 KB, application/octet-stream)
2012-10-23 05:19 PDT, Roman Zhuykov
no flags Details
patch2 (8.27 KB, application/octet-stream)
2012-10-23 05:20 PDT, Roman Zhuykov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Zhuykov 2012-10-23 05:17:48 PDT
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?
Comment 1 Roman Zhuykov 2012-10-23 05:18:39 PDT
Created attachment 170130 [details]
Comment 2 Roman Zhuykov 2012-10-23 05:19:13 PDT
Created attachment 170131 [details]
Comment 3 Roman Zhuykov 2012-10-23 05:19:48 PDT
Created attachment 170132 [details]
Comment 4 Roman Zhuykov 2012-10-23 05:20:16 PDT
Created attachment 170133 [details]
Comment 5 Alexey Proskuryakov 2012-10-23 13:45:36 PDT
If you are submitting a patch for inclusion in WebKit, please follow the steps from <http://www.webkit.org/coding/contributing.html>.
Comment 6 Roman Zhuykov 2012-11-15 06:53:50 PST
>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 ?
Comment 7 Zan Dobersek 2017-10-18 01:48:30 PDT
This is too old to be actionable.