Windows ARM64 and CORECLR_PROFILER_PATH_xxx

[ww898]

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?

[ghost]

Tagging subscribers to this area: @tommcdon Notify danmosemsft if you want to be subscribed.

[tommcdon]

@davmason

[davmason]

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.

[jkotas]

x64 emulation on ARM64 means that 64-bit can be either emulated x64 or native ARM64.

[ww898]

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 CORECLR_PROFILER_PATH_<arch> support will be included in nearest .NET5?

Thanks in advance!

P.S. I will be happy to create the pull request if you give me more information about technical details.

[davmason]

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: https://github.com/dotnet/runtime/blob/0f5948fc187c094519ef35981ff172be8afd81b5/src/coreclr/inc/clrconfigvalues.h#L514-L516

And then update here to use the new variables if the runtime is natively targeting ARM32/ARM64: https://github.com/dotnet/runtime/blob/0f5948fc187c094519ef35981ff172be8afd81b5/src/coreclr/vm/profilinghelper.cpp#L704-L712

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.

[ww898]

Hi @davmason,

As I understand, we should always use and declare in future both environment variables CORECLR_PROFILER_PATH_64 and CORECLR_PROFILER_PATH_ARM64 under Windows ARM64 and macOS ARM64 because the profiler doesn't know if the user's .NET applications will be started under an emulation or run as a native application. Is it correct?

[davmason]

Right, that is the expectation if you need to profile both native ARM32/ARM64 and emulated x86/x64.