-
Notifications
You must be signed in to change notification settings - Fork 5.3k
[release/7.0] Fixing compressed singlefile scenario on osx-arm64 #80283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Tagging subscribers to this area: @agocke, @vitek-karas, @VSadov Issue DetailsBackport of #79894 to release/7.0 /cc @VSadov Customer ImpactTestingRiskIMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
jeffschwMSFT
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved. we will take for consideration in 7.0.x
|
Approved by Tactics (7.0.3). |
|
The Mono crossaot leg seems to be stuck. I'll merge the PR. |
Backport of #79894 to release/7.0
/cc @VSadov
Customer Impact
When a user creates an app that uses both singlefile and compression and targets osx-arm64, the app cannot run.
Testing
Manual testing of the scenario. Also ran related tests, which this change fixes as well.
Risk
Low. This is a small change.
The root cause was not setting
MEM_RESERVE_EXECUTABLEflag for the memory allocated to decompress R2R assemblies.Since this is on osx-arm64 we need to play by the W^X rules. It is not possible to make writeable memory executable later on osx-arm64, if it does not have this flag when allocated.