Repository navigation
Support Runtime native build on Apple arm64. #40149
Description
Currently, there are many projects that are failing:
All failing targets
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target libunwind_dac -j 5cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target coreclrpal -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target clrgc -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target utilcode_dac -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target clrjit_static -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target cordbdi -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target superpmi -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target mcs -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target superpmi-shim-collector -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target superpmi-shim-counter -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target superpmi-shim-simple -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target ildasm -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target ilasm -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target coreclrpal_dac -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target corerun -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target coreconsole -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target utilcode -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target cordbee_wks -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target dbgshim -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target crossgen -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target clrjit -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target cee_wks_core -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target cee_wks_mergeable -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target cee_wks -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target coreclr_static -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target coreclr -j 5
cmake --build "runtime/artifacts/obj/coreclr/OSX.arm64.Checked" --target osxbundlerun -j 5
The most popular errors are:
Build errors:
/Users/seandree/git/runtime/src/coreclr/src/pal/src/libunwind_mac/src/missing-functions.c:54:34: error: use of
undeclared identifier 'X86_64_SCF_NONE'; did you mean 'AARCH64_SCF_NONE'?
return c->sigcontext_format != X86_64_SCF_NONE;
^~~~~~~~~~~~~~~
AARCH64_SCF_NONE
In file included from /Users/seandree/git/runtime/src/coreclr/src/pal/src/debug/debug.cpp:36:
/Users/seandree/git/runtime/src/coreclr/src/pal/src/include/pal/context.h:309:1: error: unknown type name
'fpsimd_context'; did you mean 'cssm_context'?
fpsimd_context* GetNativeSigSimdContext(native_context_t *mc)
/Users/seandree/git/runtime/src/coreclr/src/gc/unix/gcenv.unix.cpp:842:13: error: no matching function for call to
'ReadMemoryValueFromFile'
if (ReadMemoryValueFromFile("/sys/devices/system/cpu/cpu0/cache/index0/size", &size))
[ 0%] Building ASM object src/debug/di/CMakeFiles/cordbdi.dir/arm64/floatconversion.S.o
<instantiation>:2:9: error: unknown directive
.type FPFillR8, %function
Linking errors:
Linking CXX executable corerun
ld: warning: ignoring file ../unixcoreruncommon/libunixcoreruncommon.a, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
Undefined symbols for architecture arm64:
"GetAbsolutePath(char const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&)", referenced from:
_main in corerun.cpp.o
"ExecuteManagedAssembly(char const*, char const*, char const*, int, char const**)", referenced from:
_main in corerun.cpp.o
"GetClrFilesAbsolutePath(char const*, char const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&)", referenced from:
_main in corerun.cpp.o
"GetEntrypointExecutableAbsolutePath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&)", referenced from:
_main in corerun.cpp.o
ld: symbol(s) not found for architecture arm64
One of the root cause for these errors is that we are getting the wrong PROCESSOR in some places:
runtime/artifacts/obj/coreclr/OSX.arm64.Checked/CMakeFiles/3.18.0/CMakeSystem.cmake(4): set(CMAKE_HOST_SYSTEM_PROCESSOR x86_64 ) (TaskId:259)\
as @jashook pointed me it could be because some executables are built for x64 and are run under Rosetta2, like:
file .dotnet/dotnet
.dotnet/dotnet: Mach-O 64-bit executable x86_64
Activity
janvorli commentedon Jul 30, 2020
PAL is not aware of the possibility of arm64 on OSX, so there are several places that need to be fixed. These are mostly context related places and asm helpers.
sdmaclea commentedon Jul 31, 2020
It is not clear who is taking on this task. If no one else is working on this, I'd be happy to fix the compile issues and the assembly issues.
janvorli commentedon Jul 31, 2020
@sdmaclea I was planning to do the necessary changes in PAL, but if you have spare cycles, I'd be happy to share the work with you.
sandreenko commentedon Jul 31, 2020
My impression was that we need changes in
libunwindto fixpalbecause it is wherefpsimd_contextis declared on other platforms. Do we want to fixlibunwindin our repo first and then propagate changes to https://github.com/libunwind/libunwind or should we fix it in the master repo first? By the way, why do we have these sources checked in in our repo?janvorli commentedon Jul 31, 2020
There should be no changes needed in libunwind. The fpsimd_context is not defined in the libunwind, but in sigcontext.h on Linux. And there is no fpsimd_context for OSX. The x64 build for OSX doesn't hit the code that returns fpsimd_context. So it seems the build failure is caused by incorrectly getting to the non-OSX code due to some incorrect ifdefs.
Some of the other failures are not in the libunwind, but in the libunwind_mac which is our own addition for debugger unwinding.
sdmaclea commentedon Jul 31, 2020
@janvorli I am just getting back from vacation, but I am looking for ways to help the osx-arm64 effort. If there is a convenient split, I'd be happy to help.
janvorli commentedon Aug 3, 2020
@sdmaclea here is a list of places in PAL that need to be updated:
machexceptions.cpp
machmessage.cpp
context.cpp
dispatchexceptionwrapper.S
activationhandlerwrapper.S
context.S
unixasmmacrosarm64.inc
threadinfomac.cpp
Changes in src\coreclr\src\pal\CMakeLists.txt to add arm64 versions of the asm helpers above.
I'll be OOF from Wednesday till Sunday, so you can start making the changes and I can pick up what's left (if anything) next week.
marek-safar commentedon Aug 3, 2020
/cc @vargaz