Missing symbol for `windows_aarch64_cpu_features_arm` in `arm-64-windows` runtime

[derek-gerstmann]

I've run into a linking error on MSVS for Win ARM64 for a missing symbol in the Halide runtime (created from a recent build from Halide main):

error LNK2019: unresolved external symbol _ZN6Halide7Runtime8Internal23halide_get_cpu_featuresEv referenced in function halide_default_can_use_target_features

The halide runtime was created via a generator with target flag set to arm-64-windows.

This appears to result in an undefined symbol for the aarch64 cpu features:

> nm -u halide_runtime_arm64_windows_library.lib | grep _ZN6Halide7Runtime8Internal23halide_get_cpu_featuresEv
         U _ZN6Halide7Runtime8Internal23halide_get_cpu_featuresEv

> objdump --syms halide_runtime_arm64_windows_library.lib | grep _ZN6Halide7Runtime8Internal23halide_get_cpu_featuresEv
[1174](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 _ZN6Halide7Runtime8Internal23halide_get_cpu_featuresEv

Currently investigating this. I can confirm the Halide build has WITH_AARCH64 being detected from LLVM_COMPONENTS correctly, and tracing through the LLVM_Runtime_Linker.cpp, the get_initmod_windows_aarch64_cpu_features_arm() is being added to the list of modules, so something appears to be going wrong inside of link_modules.

[derek-gerstmann]

Inside of link_modules, the _ZN6Halide7Runtime8Internal23halide_get_cpu_featuresEv function is getting enumerated as ExternalLinkage, which would explain why it's not defined.

LLVM_Runtime_Linker.cpp:685

However, there is a similar function called ?halide_get_cpu_features@Internal@Runtime@Halide@@YA?AUCpuFeatures@123@XZ which is also getting declared, but marked as LinkOnce with CallingConv:C.

[derek-gerstmann]

For x86-64-windows, the second symbol doesn't exist, and the _ZN6Halide7Runtime8Internal23halide_get_cpu_featuresEv gets marked as LinkOnce.

[derek-gerstmann]

So it looks like there's some name mangling mismatch when using the ARM64 ABI on Windows.

The declaration for halide_get_cpu_features() defined in runtime/cpu_features.h appears to get a different symbol name than the implementation defined in runtime/windows_aarch64_cpu_features_arm.cpp.

[derek-gerstmann]

@alexreinking @abadams @zvookin @steven-johnson Any thoughts on how to resolve this?

[derek-gerstmann]

The root cause here is that the halide_get_cpu_features method returns a non-POD struct which prevents it from having C-linkage, and appears to cause ABI name mangling mismatches.

After consulting internally, it appears the most robust solution is to push this method into extern "C" linkage to avoid windows mangling. I'm working on a PR that changes the struct to POD, and modifies the linkage for all implementations.