Fix platform selection on Apple Silicon #4072
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Don't overwrite the host architecture (obtained from qHostInfo) with the process info (obtained from qProcessInfo). Differential revision: https://reviews.llvm.org/D121442 (cherry picked from commit 4ef07e5)
This patch adds a getter for the process' system architecture. I went with Process::GetSystemArchitecture to match Platform::GetSystemArchitecture. Differential revision: https://reviews.llvm.org/D121443 (cherry picked from commit 68099b1)
(cherry picked from commit 530bc61)
(cherry picked from commit a6eeffa)
To allow us to select a different platform based on where the process is running, plumb the process host architecture through platform selection. This patch is in preparation for D121444 which needs this functionality to tell apart iOS binaries running on Apple Silicon vs on a remote iOS device. Differential revision: https://reviews.llvm.org/D121484 (cherry picked from commit dde487e)
This patch is another attempt to fix platform selection on Apple Silicon. It partially undoes D117340 which tried to fix the issue by always instantiating a remote-ios platform for "iPhone and iPad Apps on Apple Silicon Macs". While the previous patch worked for attaching, it broke launching and everything else that expects the remote platform to be connected. I made an attempt to work around that, but quickly found out that there were just too may places that had this assumption baked in. This patch takes a different approach and reverts back to marking the host platform compatible with iOS triples. This brings us back to the original situation where platform selection was broken for remote iOS debugging on Apple Silicon. To fix that, we now look at the process' host architecture to differentiate between iOS binaries running remotely and iOS binaries running locally. I tested the following scenarios, which now all uses the desired platform: - Launching an iOS binary on macOS: uses the host platform - Attaching to an iOS binary on macOS: uses the host platform - Attaching to a remote iOS binary: uses the remote-ios platform rdar://89840215 Differential revision: https://reviews.llvm.org/D121444 (cherry picked from commit c22c7a6)
Some of the GDB remote client modules had been moved upstream.
|
@swift-ci please test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
rdar://89840215