kristibektashi wrote: @trungnt2910 @davemgreen @zmodem @efriedma-quic @nico @mstorsjo There's an important thing to note about ARM32 Windows compatibility with Thumb and ARM modes. It differs between the versions.
Windows NT 10.0 (Windows 10 ARM32 Desktop*/Mobile**/IoT Core** + the ARM32 compatibility layer on Windows 10/11 ARM64 builds 10586-25398***) actually supports **BOTH** the ARM **AND** Thumb modes, and can freely switch between them. Whether the compilers**** and programs themselves support it is a different problem, however the kernel freely allows using any of the two. Earlier Windows NT versions on ARM32 (6.x), aka Windows RT and Windows Phone 8.x, are the ones that do not allow ARM mode *at all*. Instead, they are limited to only Thumb mode. This is a kernel-mode limitation that afaik cannot be bypassed without kernel patching, and even so it would a) require someone to actually figure out the patch and b) be probably highly unstable. I am pretty sure that ARM mode was added on purpose on Windows 10 ARM32 for the intention of being freely used on IoT Core** devices, which had none of the Windows RT or Windows Phone limitations of running applications (although IoT Core still couldn't run full desktop Win32 apps, it could still run *some* console apps, such as cmd, and of course this is irrelevant today since full desktop ARM32 builds of Windows 10* do exist nowadays). So in my opinion I think that both ARM and Thumb modes should be added to Clang****, as well as the exception handling, however Thumb should remain the default on Windows. That way people who only target Windows 10+ will be able to use standard ARM freely, however existing programs that target Windows RT and expect that ARM == Thumb would still function. The best way to achieve this probably is to leave the target of `armv7-windows` still default to Thumb, however create a new target that explicitly targets ARM, such as `realarmv7-windows` or `armv7-arm-windows`. Or perhaps a command-line argument such as `--target-instruction-set=arm` that forces ARM instead of Thumb mode. Btw if you're interested in the communities that still care about ARM32 Windows, and especially for desktop apps for the platform, that would be either the [Open-RT](https://open-rt.party/discord) or [Windows RT Devices](https://discord.gg/wYUfxx43Jr) Discord servers, as well as some Telegram groups that are out there (you should ask about those in one of the Discord servers if you're interested). Some people on the [BetaWiki Discord](https://discord.gg/XPz5Zm42tR) might also be fairly knowledgable about all things related to ARM32 Windows. @wmjb @gailium119 @fryelum @armdevvel @windows-rt-devices (and everyone else I pinged above) I would also like your comments and opinions on this paragraph, and to fill me in in case I missed anything. *A full ARM32 Desktop build of Windows 10 does exist, it's a 1703 Insider Preview that was leaked back in 2019 (I think): https://betawiki.net/wiki/Windows_10_build_15035. This build lacks most of the limitations found on Windows RT, and therefore can run full desktop Win32 apps without jailbreaking, if they are compiled for ARM32. With the right compiler, most of the open-source apps for x86/x64/ARM64 Windows should be able to be ported to this ARM32 Windows build, as long as they support Windows 10 1703 or earlier. And of course, because it's Windows 10, it supports both ARM and Thumb modes. **Windows 10 Mobile and Windows 10 IoT Core would be very valid and interesting use cases for an ARM32-targetting Clang, since it's not that easy to e.g. install Linux or Android on W10M devices (or RT devices for that matter), and Windows 10 IoT Core 1809 LTSC is still supported until 2029. Also, you might be able to run *some* IoT Core-targetting console apps on Windows 10 Mobile if you e.g. unlock the bootloader and enable root access (with e.g. [WPInternals](https://github.com/ReneLergner/WPinternals)), then install apps like [Interop Tools](https://github.com/InteropTools/InteropTools) and [CMD Injector](https://github.com/fadilfadz01/CMD.Injector) to get acces to a shell on Windows 10 Mobile, as well as the necessary capabilities to run arbitrary code. ***Officially, Windows 10/11 versions 1709 until 23H2 support running ARM32 apps on ARM64 devices with the necessary processor capabilities. Unofficially, [they will run on builds as early as 10586 if you install certain private packages intended for Qualcomm silicon manufacturers](https://betawiki.net/wiki/Windows_10_build_10586.1078_(th2_bnb_arm64)), and will also run on builds as late as 25398, a currently unleaked build (for ARM64). This is only meant for UWP apps officially, as Win32 desktop apps on ARM32 were *never* officially supported by Microsoft *in any capacity* (excluding IoT Core console apps), however desktop ARM32 apps will still run (and without any of the RT limitations), as the entire WoW64 subsystem has been built-into these ARM64 Windows versions for both x86 (32-bit) as well as ARM32 apps, in the C:\Windows\SysWow64 and C:\Windows\SysArm32 directories respectively. This does have some limitations with ARM32 (x86 works fine), which are mostly oversights that Microsoft never bothered to fix, such as the ARM32 .NET Framework not being included on ARM64 Windows versions, and ARM32 MSI packages failing to install without a special workaround. Also interesting to note is that Microsoft seems to have intentionally blocked ARM32 Metro packages intended for Windows 8.x and Windows Phone 8.x from installing on ARM64 Windows versions, even though they install and work fine on the ARM32 Desktop version of Windows 10, and ARM32 UWP packages targetting Windows 10 also obviously install fine on ARM64 Windows (as these were officially supported). This is known to be 100% intentional as there's a special error message that shows up when you try to install a Metro Windows RT application on an ARM64 Windows version. ****I'm unaware to which degree Clang officially supports proper ARM (instead of Thumb) on Windows ARM32 targets, if at all. I do think that support should be added, and it should probably be trivial to combine the existing ARM generator code that already exists and is being used for e.g. Linux with the existing Windows-specific code for the Thumb target, and thus allow the user to choose which one to use (as mentioned above), however that is a separate issue entirely. https://github.com/llvm/llvm-project/pull/184953 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
