RESOLVED FIXED Bug 213653
[webkitpy] Automatically detect hw architecture for supporting Apple Silicon
https://bugs.webkit.org/show_bug.cgi?id=213653
Summary [webkitpy] Automatically detect hw architecture for supporting Apple Silicon
Jonathan Bedard
Reported 2020-06-26 12:36:16 PDT
webkitpy needs to support Macs with an arm64 architecture and needs some testing support for Rosetta.
Attachments
Patch (11.41 KB, patch)
2020-06-26 12:47 PDT, Jonathan Bedard
no flags
Patch (11.27 KB, patch)
2020-06-26 14:21 PDT, Jonathan Bedard
no flags
Patch (11.31 KB, patch)
2020-06-26 14:32 PDT, Jonathan Bedard
no flags
Patch for landing (11.38 KB, patch)
2020-06-26 14:38 PDT, Jonathan Bedard
no flags
Radar WebKit Bug Importer
Comment 1 2020-06-26 12:36:40 PDT
Jonathan Bedard
Comment 2 2020-06-26 12:47:52 PDT
Jonathan Bedard
Comment 3 2020-06-26 12:50:01 PDT
(In reply to Jonathan Bedard from comment #2) > Created attachment 402888 [details] > Patch This doesn't handle Rosetta yet, but it means that machines running on Apple Silicon with native WebKit will report correctly.
Aakash Jain
Comment 4 2020-06-26 14:12:08 PDT
Comment on attachment 402888 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=402888&action=review > Tools/Scripts/webkitpy/common/system/platforminfo.py:117 > + if output == 'arm64e': This will never be true since output is assigned to arm64 in above line when it's arm64e.
Jonathan Bedard
Comment 5 2020-06-26 14:21:02 PDT
Aakash Jain
Comment 6 2020-06-26 14:23:55 PDT
Comment on attachment 402901 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=402901&action=review > Tools/ChangeLog:3 > + [webkitpy] Support Apple Silicon (Part 1) Bug title can be little more descriptive. Like: [webkitpy] Automatically detect hw architecture for supporting Apple Silicon > Tools/Scripts/webkitpy/common/system/platforminfo.py:111 > + try: can we avoid running 'uname -m' command when is_mac() is false and have an early return instead?
Jonathan Bedard
Comment 7 2020-06-26 14:28:23 PDT
(In reply to Aakash Jain from comment #6) > Comment on attachment 402901 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=402901&action=review > > > Tools/ChangeLog:3 > > + [webkitpy] Support Apple Silicon (Part 1) > > Bug title can be little more descriptive. Like: [webkitpy] Automatically > detect hw architecture for supporting Apple Silicon > > > Tools/Scripts/webkitpy/common/system/platforminfo.py:111 > > + try: > > can we avoid running 'uname -m' command when is_mac() is false and have an > early return instead? I don't think we should. We have multiple watchOS architectures, the same logic should apply. That's actually the whole reason I didn't use the os version of that function in the first place.
Jonathan Bedard
Comment 8 2020-06-26 14:32:04 PDT
Aakash Jain
Comment 9 2020-06-26 14:35:18 PDT
Comment on attachment 402901 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=402901&action=review > Tools/Scripts/webkitpy/common/system/platforminfo_mock.py:43 > + ).get(self.os_name, 'x86') should the default be x86 or x86_64? > Tools/Scripts/webkitpy/port/mac.py:72 > + return 'arm64' might be worth adding a comment here for the reason of doing this.
Aakash Jain
Comment 10 2020-06-26 14:35:33 PDT
rs=me
Jonathan Bedard
Comment 11 2020-06-26 14:38:06 PDT
Created attachment 402905 [details] Patch for landing
EWS
Comment 12 2020-06-26 15:10:03 PDT
Committed r263592: <https://trac.webkit.org/changeset/263592> All reviewed patches have been landed. Closing bug and clearing flags on attachment 402905 [details].
Fujii Hironori
Comment 13 2020-06-27 18:07:10 PDT
Comment on attachment 402905 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=402905&action=review > Tools/Scripts/webkitpy/port/base.py:-116 > - self.set_option('architecture', self.DEFAULT_ARCHITECTURE) Removing this code causes a trouble for Windows ports. Filed : Bug 213688 – [Win] run-webkit-tests is failing to run DRT and WTR without --architecture x86_64
Note You need to log in before you can comment on or make changes to this bug.