Skip to content
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

Add arm64 architecture to the shared store #2181

Closed
pjanotti opened this issue Feb 9, 2023 · 5 comments · Fixed by #3277
Closed

Add arm64 architecture to the shared store #2181

pjanotti opened this issue Feb 9, 2023 · 5 comments · Fixed by #3277
Assignees
Milestone

Comments

@pjanotti
Copy link
Contributor

pjanotti commented Feb 9, 2023

The list at dotnet/runtime has other values but because of Apple M1 boxes, we may want to provide arm64 by default.

Adding all arch to the shared store doesn't seem scalable, ideally, we would have a way to automatically select the proper |arch|/|tfm| pair upon installing on the box. However, as mentioned, arm64 may be popular enough to justify its addition even without the general mechanism.

Temporary Workaround: rename $DOTNET_SHARED_STORE/x64/ to $DOTNET_SHARED_STORE/arm64/. The assemblies under the folder are IL only so source instrumentations are expected to work without issues. The native component is not supported on arm64 yet and given that the default rule engine will fail startup if it is enabled it needs to be disabled removing or setting the environment variable CORECLR_ENABLE_PROFILING to 0.

[EDIT 01: Update workaround since it is not going to work with the default rule engine checks.]

@pjanotti
Copy link
Contributor Author

pjanotti commented Feb 9, 2023

One possibility is to create symbolic links to a single architecture since we use the same IL-only components.

@rajkumar-rangaraj
Copy link
Contributor

Today, even I was exploring about symbolic link. If we get this working we could reduce our package size by and solve issues for all architecture.

@Kielek
Copy link
Contributor

Kielek commented Feb 9, 2023

I am not sure if it will be good idea to support only managed code on arm64.
It should be done together with #1865

@pellared
Copy link
Member

pellared commented Feb 9, 2023

I am not sure if it will be good idea to support only managed code on arm64. It should be done together with #1865

I think it is OK. Better than nothing. Especially that we even document that it is possible to work without .NET Profiler here

@Kielek
Copy link
Contributor

Kielek commented Apr 26, 2023

Removing from 1.0.0-rc milestone. I think that we can add this support after 1.0.0 release, both for sourcecode and bytecode instrumenation. I would like to avoid only partial support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants