Support x86 for NativeAOT

[kant2002]

I know that x86 is legacy right now, but come across person who what to write anti-cheat for x86 game using NativeAOT.
I know that's fringe case, and I prefer to have better case asking for support me on this journey.

So my question would be following: If I put some efforts into this, would this be a burden for core team?

[MichalStrehovsky]

Anti-cheat... I assume you're asking x86 Windows specifically?

[kant2002]

Yes, I was thinking about Windows x86.

[MichalStrehovsky]

So my question would be following: If I put some efforts into this, would this be a burden for core team?

I'll let @jkotas answer that. My estimate is that x86 Windows will be orders of magnitude more work than what was needed for ARM32 Linux (ARM32 Linux was already mostly there thanks to Samsung's work in the past). x86 in general is an unpleasant architecture to work with, possibly more so on Windows than Linux. A lot of legacy weird cruft was fixed with x86-64.

[jkotas]

x86 was done in the past for UWP. We have a lot of the x86 code there, so I would not say that fixing that code up and filling in the missing pieces would be a significant burden. I agree with @MichalStrehovsky that Windows x86 in general is an unpleasant architecture to work with and fixing it up is likely going to be much harder than fixing up ARM32.

[kant2002]

I immediately hit something not very pleasant.
The USE_GC_INFO_DECODER not defined on x86, so I have compilation errors in CoffNativeCodeManager::EnumGcRefs , CoffNativeCodeManager::GetConservativeUpperBoundForOutgoingArgs and CoffNativeCodeManager::UnwindStackFrame. From what I understand I need to reimplement methods from EECodeManager, but for example EnumGcRefs is quite a bit of code and I may need add eetwain.cpp to Runtime. Are there any better way?

[Suchiman]

Another thing i remember that also needs to be enabled for x86 is exception handling which is vastly different between x86 and x64 (at least in CoreCLR). IIRC the x86 mechanism is not implemented in CoreRT but the x64 mechanism could be used on x86 but it requires building the JIT with FEATURE_EH_FUNCLETS enabled which is untested for x86.

[jkoritzinsky]

It would be interesting to try to build Windows x86 on NativeAOT more like how CoreCLR's (unofficial, for Tizen only) x86 Linux support is built instead of how CoreCLR does Windows x86 support. x86 Linux is much more similar to the rest of the supported platforms than x86 Windows in terms of implementation.

[kant2002]

It would be interesting to try to build Windows x86 on NativeAOT more like how CoreCLR's (unofficial, for Tizen only) x86 Linux support is built

@jkoritzinsky Can you feed me with details of differences, and how I may pursue that direction? If making Linux x86 works would be faster and pave road to Win x86, I may start even with that.

[jkoritzinsky]

So there's a few differences I know off the top of my head. I'll include a little table below with my recommendations for what to do for CoreRT Windows x86 support (note these are my gut recommendations and might be wrong or unneeded for NativeAOT).

Primarily, many of the Windows x86 differences aren't due to actual requirements, but due to the fact that the x86 models were the first designed in .NET Framework, and all the future architecture models learned from the mistakes of Windows x86.

Item	CoreCLR Windows x86	CoreCLR Linux x86	NativeAOT x64	Suggestion
Calling Convention	Fastcall-like	Cdecl + extra registers + same limitations as fastcall-like	platform default	Fastcall-like
GC Info encoding	custom encode/decode	USE_GC_INFO_DECODER encode/decode	USE_GC_INFO_DECODER encode/decode	USE_GC_INFO_DECODER encode/decode
Exception handling	!FEATURE_EH_FUNCLETS	FEATURE_EH_FUNCLETS	FEATURE_EH_FUNCLETS	FEATURE_EH_FUNCLETS unless special handling is required for SEH-interop

Basically you should try just turning on the USE_GC_INFO_DECODER and FEATURE_EH_FUNCLETS defines for x86 and see how far you can get with x86 support. I think you'll be able to make a lot of progress by going in this direction instead of trying to port over CoreCLR's Windows x86's weirdness to NativeAOT.

[kant2002]

Thanks a lot, that clarify all your point, and make my life so much easier. At least I now understand about why bifurcation happens, and what I have option to make small decisions my self, like if I encounter some wierdness, then I may check that this is x86 weirdness, and just try to go with different path.

Basically you should try just turning on the USE_GC_INFO_DECODER and FEATURE_EH_FUNCLETS defines for x86 and see how far you can get with x86 support

Will try it out, and see how it goes.

[CeSun]

A better option for developers maintaining old x86 projects?
The exe of the program I am maintaining now has lost the source code, I can only develop dll, but I am tired of c++ and want to use c# to develop.

[sweetjian]

Support for x86 programs is expected