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.
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
[release/6.0] x64 on ARM64 fixes #59295
[release/6.0] x64 on ARM64 fixes #59295
Changes from all commits
631b061
9be9002
e1c5dc8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
uname -m
will give you x86_64 under rosetta emulation. Is this the intended behavior?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.
If someone is really running this installer package under Rosetta emulation, then yes I think that should be the expected behavior.
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.
I added a card to our board to test this. I'm not so worried about accidentally setting path, that's easy to fix and user can change it per their intent. I am worried if somehow we can lie to the installer javascript detection, since that would put the files in the wrong place. @sfoslund https://github.com/orgs/dotnet/projects/38#card-69051611
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.
I believe this is against what was proposed - only setting path of dotnet for the native one. I'm ok with it either way.
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.
If user’s intention is to “Run as x86_64 app” on arm64 host, in that case “native” is the target of emulation/virtualization and x86_64 behavior is expected. This is how other software (including Apple’s own) handle this case.
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.
Interesting, I just tried this out and I think I found a way to test it.
If I create a terminal that runs using rosetta, then launch the installer from that ternminal I see it report
hw.machine
asx86_64
on my M1. This is not good, we don't want the installer to be lied to.@sfoslund here's the command I ran to do this:
sudo installer -dumplog -verboseR -pkg testPkg.pkg -target /
We should check the newer detection you added and see if that's avoiding this redirection.
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.
I just tried the repro with latest detection and it also sees the x64 values when run from rosetta terminal.
I found at least one way to identify when this is happening: https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment.
sysctl.proc_translated
--> this returns 1 when run from rosetta. I wonder if that's a sufficient escape hatch for our purposes.I opened #59370 to track this.
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.
I was considering it as a correct behavior based on how other installers (node.js, rustup and so on) operate in Rosetta2, and more generally, any emulation environments (qemu). Forcing our will against user wishes is no good, IMO.
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.
Based on my quick research, it looks like we can detect if we're running in rosetta with
sysctl -in sysctl.proc_translated
. Do we just want to try to block the install in this case? Or should we add this check to our logic for determining if a machine is x64?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.
@am11 perhaps you can open an issue with a scenario that you feel is blocked and we can discuss that?
We're actually making the runtime aware of emulation and making it so both x64 and ARM64 can coexist. The problem is that existing installers weren't aware and would clash. We're preserving the single entrypoint, so we do have to make the installers aware of real architecture so that they can avoid clashing. This is the part we can't have lied to, since that circumvents the work. The rest of the runtime is happy to be lied to, that's what the support for this is all about.
This file was deleted.