[llvm-lipo] llvm-lipo support for arm64x windows?

[trcrsired]

I think llvm-lipo should work for hybrid binary for windows on arm. What do you think?

[trcrsired]

@cjacek

[cjacek]

ARM64X images work differently from Mach-O universal binaries (though I admit I have no experience with the latter). They are truly a single PE file containing code for both the EC and native targets. The two views share the same sections. For example, there is a single .text section containing code for both native and EC views. We can't achieve this by merging two separate images since each would expect different things at the same RVAs.

Generating ARM64X images must be done by the linker so it can account for these differences. LLD support for creating ARM64X binaries is nearing completion.

The distinction between native and EC views is entirely handled by ARM64X dynamic relocations. For the native view, the image is valid as-is (which is why Windows 10, despite lacking ARM64X relocation support, can still load ARM64X images). For the EC view, those relocations are applied at runtime. A possible equivalent to "extracting" the EC variant of the image would be generating an output with relocations already applied (and possibly stripped). This might be useful for inspecting ARM64X binaries. It should be easy to implement since we already have COFFObjectFile::getHybridObjectView, which returns an image with ARM64X relocations applied (used by llvm-readobj to dump hybrid view information).

There are no hybrid object files for ARM64X. To build ARM64X binaries, one must produce separate ARM64 and ARM64EC object files and pass both to the linker. This approach is quite unconventional and may pose challenges for build systems that don’t expect it. In theory, we could introduce hybrid object files to simplify this process, but that’s not how MSVC handles it, and it’s unclear if it would be worth the effort. If we did, merging/extracting them might make sense.

[trcrsired]

ARM64X images work differently from Mach-O universal binaries (though I admit I have no experience with the latter). They are truly a single PE file containing code for both the EC and native targets. The two views share the same sections. For example, there is a single .text section containing code for both native and EC views. We can't achieve this by merging two separate images since each would expect different things at the same RVAs.

Generating ARM64X images must be done by the linker so it can account for these differences. LLD support for creating ARM64X binaries is nearing completion.

The distinction between native and EC views is entirely handled by ARM64X dynamic relocations. For the native view, the image is valid as-is (which is why Windows 10, despite lacking ARM64X relocation support, can still load ARM64X images). For the EC view, those relocations are applied at runtime. A possible equivalent to "extracting" the EC variant of the image would be generating an output with relocations already applied (and possibly stripped). This might be useful for inspecting ARM64X binaries. It should be easy to implement since we already have COFFObjectFile::getHybridObjectView, which returns an image with ARM64X relocations applied (used by llvm-readobj to dump hybrid view information).

There are no hybrid object files for ARM64X. To build ARM64X binaries, one must produce separate ARM64 and ARM64EC object files and pass both to the linker. This approach is quite unconventional and may pose challenges for build systems that don’t expect it. In theory, we could introduce hybrid object files to simplify this process, but that’s not how MSVC handles it, and it’s unclear if it would be worth the effort. If we did, merging/extracting them might make sense.

It looks like Microsoft has really messed things up. Instead of using a universal binary approach like Apple does with Mach-O, they chose to implement ARM64EC. With Intel APX increasing the number of general-purpose registers (GPRs) to 32, the one-to-one mapping of ARM64EC won't align with the new GPRs in x86_64 APX. This means that Intel APX could completely break ARM64EC.

What are your thoughts? Do you believe ARM64EC could function correctly with Intel APX under these circumstances?

[trcrsired]

@cjacek
By the way, Jacek. Can you have a look at this? I need this in the upstream to support my GNU style windows sysroot for msvc target
https://github.com/trcrsired/windows-msvc-sysroot

690011a

[cjacek]

It looks like Microsoft has really messed things up. Instead of using a universal binary approach like Apple does with Mach-O, they chose to implement ARM64EC.

I think Microsoft had good reasons for taking this approach. There are fundamental differences in how PE files work: they don’t have load commands or similar mechanisms to leverage. Achieving this would require significant extensions (or even a new format), which would prevent ARM64X from working on older Windows versions and could also confuse emulated x86 environments, which often make assumptions about system library formats. Additionally, ARM64X enables significant data sharing between views, making its design more space-efficient.

With Intel APX increasing the number of general-purpose registers (GPRs) to 32, the one-to-one mapping of ARM64EC won't align with the new GPRs in x86_64 APX. This means that Intel APX could completely break ARM64EC.

I don’t think that’s what registry mapping implies. ARM64EC code already has access to most registers, only a few are disallowed, so it’s already quite close to what ARM64 hardware allows. The x87 mapping is primarily relevant for fitting the CPU context into the Win32 CONTEXT struct, which can’t be changed for obvious reasons. However, ARM64EC freely uses all allowed registers without constraints imposed by their appearance as x87 registers to x86 code.

APX requires an extended version of the CONTEXT struct (similar to SSE2, AVX, etc.). In theory, it could be used to map the remaining ARM registers to APX registers, but that wouldn’t offer much benefit since ARM64EC already has access to most hardware registers.

Emulating APX is a separate issue, but the JIT emulator itself isn’t necessarily constrained by the mapping you mentioned. I could imagine additional APX registers being mapped to ARM registers in JIT. Supporting code that mixes x87 and APX might require some extra care, but it doesn’t seem like an unsolvable problem.

By the way, Jacek. Can you have a look at this? I need this in the upstream to support my GNU style windows sysroot for msvc target

You appear to be using Microsoft copyrighted headers, which raises concerns about distribution rights.

For what it's worth, Wine includes headers and libraries that enable using Clang’s MSVC target in a fully open-source environment. The simplest way to leverage this is to install a Wine build with Clang and then use winegcc -b aarch64-windows .... winegcc is essentially a wrapper around the compiler to streamline usage, but you can also configure plain clang to work.

That said, C++ support currently requires patching Wine, so it might not yet fully meet your needs...

[trcrsired]

It looks like Microsoft has really messed things up. Instead of using a universal binary approach like Apple does with Mach-O, they chose to implement ARM64EC.

I think Microsoft had good reasons for taking this approach. There are fundamental differences in how PE files work: they don’t have load commands or similar mechanisms to leverage. Achieving this would require significant extensions (or even a new format), which would prevent ARM64X from working on older Windows versions and could also confuse emulated x86 environments, which often make assumptions about system library formats. Additionally, ARM64X enables significant data sharing between views, making its design more space-efficient.

With Intel APX increasing the number of general-purpose registers (GPRs) to 32, the one-to-one mapping of ARM64EC won't align with the new GPRs in x86_64 APX. This means that Intel APX could completely break ARM64EC.

I don’t think that’s what registry mapping implies. ARM64EC code already has access to most registers, only a few are disallowed, so it’s already quite close to what ARM64 hardware allows. The x87 mapping is primarily relevant for fitting the CPU context into the Win32 CONTEXT struct, which can’t be changed for obvious reasons. However, ARM64EC freely uses all allowed registers without constraints imposed by their appearance as x87 registers to x86 code.

APX requires an extended version of the CONTEXT struct (similar to SSE2, AVX, etc.). In theory, it could be used to map the remaining ARM registers to APX registers, but that wouldn’t offer much benefit since ARM64EC already has access to most hardware registers.

Emulating APX is a separate issue, but the JIT emulator itself isn’t necessarily constrained by the mapping you mentioned. I could imagine additional APX registers being mapped to ARM registers in JIT. Supporting code that mixes x87 and APX might require some extra care, but it doesn’t seem like an unsolvable problem.

By the way, Jacek. Can you have a look at this? I need this in the upstream to support my GNU style windows sysroot for msvc target

You appear to be using Microsoft copyrighted headers, which raises concerns about distribution rights.

For what it's worth, Wine includes headers and libraries that enable using Clang’s MSVC target in a fully open-source environment. The simplest way to leverage this is to install a Wine build with Clang and then use winegcc -b aarch64-windows .... winegcc is essentially a wrapper around the compiler to streamline usage, but you can also configure plain clang to work.

That said, C++ support currently requires patching Wine, so it might not yet fully meet your needs...

No. i use this sysroot to cross compile windows msvc binary. Many targets like mac and android do not necessarily support winegcc and even they do winegcc is just painful to use.

i do not see how this violates copyrighted headers,given all of them comes from microsoft and i just rearrange how the headers are located as other targets do. The UNIX sysroot like convention everyone can package themselves. include, lib, share etc which is the --sysroot in clang and gcc mean.

I can guarantee it breaks apx since i compiled binaries with mapxf it does not run on my surface laptop 7 and i have a new calling convention called wincall which is incompatible with arm64ec either.
https://developercommunity.visualstudio.com/t/I-present-a-novel-calling-convention-nam/10433601?q=wincall

ARM64X does not run on x86 so it already breaks things. Universal binary is not an issue for old systems at all given microsoft can just add another vc distribution. the mainstream 64 bit windows support starts with win7 and win7 had been long way end of support. Even windows10 is near its end. Patching them to support the universal binary is not an issue.

I would argue even syswow64 needs to be completely eliminated and replaced with universal binary with i686/x86_64 on x86_64 windows, i686/x86_64/aarch64 windows.
The problem is that many app vendors are unwilling to ship binaries for multiple architectures since it confuses consumers. Blizzard battle.net is one example. They only ship 32 bit x86 windows binary of battle.net

[cjacek]

I can guarantee it breaks apx since i compiled binaries with mapxf it does not run on my surface laptop 7 and i have a new calling convention called wincall which is incompatible with arm64ec either.

Yes, APX isn't supported, but that's due to a lack of implementation rather than any fundamental limitation in the ARM64EC ABI.

[trcrsired]

I can guarantee it breaks apx since i compiled binaries with mapxf it does not run on my surface laptop 7 and i have a new calling convention called wincall which is incompatible with arm64ec either.

Yes, APX isn't supported, but that's due to a lack of implementation rather than any fundamental limitation in the ARM64EC ABI.

i think it is fundamental limitation since microsoft has one to one mapping that just breaks things.

Also with the wincall i proposed it needs to use r16 r17 r18 r19 for passing parameters since windows x86_64 calling convention is terrible

[trcrsired]

https://github.com/trcrsired/windows-msvc-sysroot/tree/main
https://github.com/trcrsired/llvm-releases/releases/tag/llvm21-20250220

BTW i compile windows msvc binaries on my phones with this one. and it supports a lot of things neither mingw-w64 and wine support. Like winrt/winui3 support. Microsoft STL support and i also added correct support for clang under libc++. libc++`s c++.dll(msvc target variant dll name) support. they are different targets.

arm64ec is not only useless for me but also adds tons of burdens to maintain for 3rd party libraries since arm64ec confuses libraries under basic assumptions of both x86 and arm intrinsics and symbols work

[trcrsired]

https://github.com/cppfastio/fast_io/blob/next/include/fast_io_core_impl/allocation/msvc/msvc_linker_arm64ec.h

https://github.com/cppfastio/fast_io/blob/next/include/fast_io_hosted/platforms/win32/msvc_linker_arm64ec.h

the entire thing of arm64ec is just too painful tbh.
While normal aarch64 and every other 64 bits architecture use the same naming as x86_64 do.
https://github.com/cppfastio/fast_io/blob/next/include/fast_io_hosted/platforms/win32/msvc_linker_64.h

cppfastio/fast_io@ff6156f
Last day i tried to support arm64ec. It needs to change 10k lines of code for a library that is less than 100k lines in total. That is pain as ass tbh. It helps nothing for transition while adds tons of issues and pain. A lot of people, not just me, think microsoft has lost the plot of woa.

see this video he talked about the same issue that windows has no universal binary support.
https://youtu.be/qKRmYW1D0S0?feature=shared&t=1873