WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 170672
[aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate()
https://bugs.webkit.org/show_bug.cgi?id=170672
Summary
[aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 und...
Zan Dobersek
Reported
2017-04-10 05:09:32 PDT
[aarch64][Linux] m_allowScratchRegister assert hit in MacroAssembler64 under B3::Air::CCallSpecial::generate()
Attachments
Patch
(1.85 KB, patch)
2017-04-10 05:24 PDT
,
Zan Dobersek
no flags
Details
Formatted Diff
Diff
Verbose compilation output of a failing stress test
(189.40 KB, text/plain)
2017-04-25 04:58 PDT
,
Zan Dobersek
no flags
Details
Patch
(4.38 KB, patch)
2017-05-01 05:56 PDT
,
Zan Dobersek
no flags
Details
Formatted Diff
Diff
Patch
(4.38 KB, patch)
2017-05-01 06:06 PDT
,
Zan Dobersek
no flags
Details
Formatted Diff
Diff
Archive of layout-test-results from ews112 for mac-elcapitan
(1.77 MB, application/zip)
2017-05-01 13:35 PDT
,
Build Bot
no flags
Details
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Zan Dobersek
Comment 1
2017-04-10 05:24:30 PDT
Created
attachment 306686
[details]
Patch
Yusuke Suzuki
Comment 2
2017-04-10 19:55:23 PDT
Comment on
attachment 306686
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=306686&action=review
Nice, r=me with comment.
> Source/JavaScriptCore/b3/air/AirCCallSpecial.cpp:137 > + jit.call(scratchRegister);
Could you add a test to testair to ensure that the bug is fixed?
Yusuke Suzuki
Comment 3
2017-04-10 20:20:06 PDT
Comment on
attachment 306686
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=306686&action=review
>> Source/JavaScriptCore/b3/air/AirCCallSpecial.cpp:137 >> + jit.call(scratchRegister); > > Could you add a test to testair to ensure that the bug is fixed?
And I think it is not necessary for x86. Please add `isX86()` guard.
Zan Dobersek
Comment 4
2017-04-16 13:35:34 PDT
(In reply to Yusuke Suzuki from
comment #2
)
> Comment on
attachment 306686
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=306686&action=review
> > Nice, r=me with comment. > > > Source/JavaScriptCore/b3/air/AirCCallSpecial.cpp:137 > > + jit.call(scratchRegister); > > Could you add a test to testair to ensure that the bug is fixed?
I'm having some issues constructing the test in testair. As far as I understand a valid B3::CCallValue object is necessary when generating the Patch instruction that uses the problematic CCallSpecial. That requires including a bunch of B3 classes into testair.cpp, which I'm not certain is acceptable. Testing this in testb3 might also be difficult because the problem manifests when using an optimization level lower than the default (2).
Saam Barati
Comment 5
2017-04-17 13:19:16 PDT
(In reply to Zan Dobersek from
comment #4
)
> (In reply to Yusuke Suzuki from
comment #2
) > > Comment on
attachment 306686
[details]
> > Patch > > > > View in context: > >
https://bugs.webkit.org/attachment.cgi?id=306686&action=review
> > > > Nice, r=me with comment. > > > > > Source/JavaScriptCore/b3/air/AirCCallSpecial.cpp:137 > > > + jit.call(scratchRegister); > > > > Could you add a test to testair to ensure that the bug is fixed? > > I'm having some issues constructing the test in testair. As far as I > understand a valid B3::CCallValue object is necessary when generating the > Patch instruction that uses the problematic CCallSpecial. That requires > including a bunch of B3 classes into testair.cpp, which I'm not certain is > acceptable. > > Testing this in testb3 might also be difficult because the problem manifests > when using an optimization level lower than the default (2).
I think you should test it in testb3 and then just manually set the optimization level on the procedure you create.
Saam Barati
Comment 6
2017-04-24 12:54:12 PDT
Any luck writing a test, Zan?
Zan Dobersek
Comment 7
2017-04-25 04:29:56 PDT
(In reply to Saam Barati from
comment #6
)
> Any luck writing a test, Zan?
No. I'm able to write out a minimized B3 procedure that ends up generating a CCall instruction in Air, but I can't determine what gets the callee argument generated in the address form in the stress tests so that I could reproduce that in the B3 test case.
Zan Dobersek
Comment 8
2017-04-25 04:58:14 PDT
Created
attachment 308092
[details]
Verbose compilation output of a failing stress test Here's the verbose compilation output for one failing stress test. Right before the Air generation, there are two problematic patchpoints that use the callee in address form, in BB#10 and BB#22. If anyone wants to take this over, feel free to do so.
Zan Dobersek
Comment 9
2017-05-01 05:38:38 PDT
The problem turned out to be a combination of linear scan usage (enabled when optimization level is lowered below 2) and the callee argument of a Air::CCallSpecial being spilt on the stack.
Zan Dobersek
Comment 10
2017-05-01 05:56:31 PDT
Created
attachment 308715
[details]
Patch
Build Bot
Comment 11
2017-05-01 05:58:17 PDT
Attachment 308715
[details]
did not pass style-queue: ERROR: Source/JavaScriptCore/b3/testb3.cpp:10456: Consider using CHECK_EQ instead of CHECK(a == b) [readability/check] [2] Total errors found: 1 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
Zan Dobersek
Comment 12
2017-05-01 06:06:23 PDT
Created
attachment 308716
[details]
Patch
Zan Dobersek
Comment 13
2017-05-01 06:07:16 PDT
(In reply to Zan Dobersek from
comment #12
)
> Created
attachment 308716
[details]
> Patch
This takes a different approach, disallowing spilling the callee argument on the stack for ARM64. I'm not sure this is preferable to special-casing for the Arg::Addr callee in generate() (as proposed in
comment #3
) -- input welcome.
Saam Barati
Comment 14
2017-05-01 10:23:45 PDT
(In reply to Zan Dobersek from
comment #13
)
> (In reply to Zan Dobersek from
comment #12
) > > Created
attachment 308716
[details]
> > Patch > > This takes a different approach, disallowing spilling the callee argument on > the stack for ARM64. I'm not sure this is preferable to special-casing for > the Arg::Addr callee in generate() (as proposed in
comment #3
) -- input > welcome.
Why doesn't this effect x86? Can it encode calls to arbitrary addresses?
Saam Barati
Comment 15
2017-05-01 10:24:14 PDT
Fil, Michael, any thoughts?
Filip Pizlo
Comment 16
2017-05-01 10:26:17 PDT
(In reply to Saam Barati from
comment #14
)
> (In reply to Zan Dobersek from
comment #13
) > > (In reply to Zan Dobersek from
comment #12
) > > > Created
attachment 308716
[details]
> > > Patch > > > > This takes a different approach, disallowing spilling the callee argument on > > the stack for ARM64. I'm not sure this is preferable to special-casing for > > the Arg::Addr callee in generate() (as proposed in
comment #3
) -- input > > welcome. > > Why doesn't this effect x86? Can it encode calls to arbitrary addresses?
Yes.
Build Bot
Comment 17
2017-05-01 13:35:05 PDT
Comment on
attachment 308716
[details]
Patch
Attachment 308716
[details]
did not pass mac-debug-ews (mac): Output:
http://webkit-queues.webkit.org/results/3653003
New failing tests: fast/dom/Window/slow-unload-handler-overwritten-date.html
Build Bot
Comment 18
2017-05-01 13:35:07 PDT
Created
attachment 308759
[details]
Archive of layout-test-results from ews112 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews112 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Zan Dobersek
Comment 19
2017-05-01 21:32:11 PDT
Comment on
attachment 308716
[details]
Patch Clearing flags on attachment: 308716 Committed
r216058
: <
http://trac.webkit.org/changeset/216058
>
Zan Dobersek
Comment 20
2017-05-01 21:32:15 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug