-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Windows ARM64 and CORECLR_PROFILER_PATH_xxx #39699
Comments
Tagging subscribers to this area: @tommcdon |
Hi @ww898, Our team is not currently working on anything like this, and the soonest it would be scheduled is the .net 6 timeframe (although it could be later). As always we are happy to accept community patches. FYI the .net 5 release is quickly wrapping up, we are already past feature release and this sort of change would only reliably get in for the next month or so. I would have to think about the design of this a little more. The issue is that as far as I know the runtime is unaware when it's operation in x86 emulation on arm vs running natively on x86 hardware. My suspicion is that adding one variable would be enough, since CORECLR_PROFILER_PATH_64 and CORECLR_PROFILER_PATH_32 should work as expected when running arm native apps. It's only the x86 emulation part that would need a special variable. |
x64 emulation on ARM64 means that 64-bit can be either emulated x64 or native ARM64. |
Hi @noahfalk, I would like to make the situation a little bit clear for Apple Silicon M1 computers. As I know .NET 5.0 is waiting some fixes from macOS Big Sur to run under Rosetta 2. My question is about activation. Probably, It will be required in nearest future to run .NET5 x64 + Rosetta 2 and .NET6 arm64 on the same macOS computer. Am I right if expect the Thanks in advance! P.S. I will be happy to create the pull request if you give me more information about technical details. |
There hasn't been any work on this issue yet. If you are willing to put together a PR for inclusion in 6.0, it should be fairly simple. You would add two more variables CORECLR_PROFILER_PATH_ARM32 and CORECLR_PROFILER_PATH_ARM64 here: runtime/src/coreclr/inc/clrconfigvalues.h Lines 514 to 516 in 0f5948f
And then update here to use the new variables if the runtime is natively targeting ARM32/ARM64: runtime/src/coreclr/vm/profilinghelper.cpp Lines 704 to 712 in 0f5948f
The logic should be if targeting ARM natively use the ARM32/ARM64 variables first, then use the CORECLR_PROFILER_PATH_32/64 variable only if the previous ones aren't set, then use CORECLR_PROFILER_PATH only if all of the previous ones aren't set. I would really like to avoid adding environtment variables for every architecture we target, this way when running on ARM32/64 you can set CORECLR_PROFILER_PATH_32/64 to target the profiler in emulation and CORECLR_PROFILER_PATH_ARM32/ARM64 to target the profiler running natively. |
Hi @davmason, As I understand, we should always use and declare in future both environment variables |
Right, that is the expectation if you need to profile both native ARM32/ARM64 and emulated x86/x64. |
Hi Everybody,
Windows ARM64 has 3 architecture in installation: ARM64, ARM and x86. My question is about CORECLR_PROFILER_PATH_32. How can I select separate profiler DLLs for x86 and ARM architectures?
Can CoreCLR team implement something like CORECLR_PROFILER_PATH_ARM, CORECLR_PROFILER_PATH_X86 and CORECLR_PROFILER_PATH_ARM64 or you already have better solution?
The text was updated successfully, but these errors were encountered: