Fix build issues with the newer v6 aot compiler about efisharp HOT 7 CLOSED

I have just figured out how to build with the v6 ilc by only using dotnet publish for its access to ilc and then manually calling link.exe with link "obj\x64\Release\net5.0\win-x64\native\EfiSharp.obj" /subsystem:EFI_APPLICATION /entry:EfiMain ..\EfiSharp.Native\x64\release\EFiSharp.Native.lib.
This is to get around ilc v6 introducing its own /subsystem and /entry arguments and also adding in runtime.lib and bootstrapper.lib. It appears I was not the only one to discover this change as at roughly the same time I was trying figuring this out, dotnet/runtimelab#633 was posted.

Ideally, I would be able to use the stock runtime.lib or at least the portable version but current attempts result in quite a few unresolved externals.

I have tried to work around this on the NativeAOT-Test.Corelib-RuntimeFix branch but even fixing all errors just allows the wrong entry point to be used.

from efisharp.

Attempting to join both the v6 and runtime changes does resolve the errors in the previous image but leads instead to over a hundred missing external symbols in low level functions.

At least some of the ones in MathHelpers.obj appear due to no c runtime which could be solved with a freestanding one like mlibc but most appear specific to the dotnet.

from efisharp.

At least some of the ones in MathHelpers.obj appear due to no c runtime which could be solved with a freestanding one like mlibc but most appear specific to the dotnet.

Yep, this is missing C runtime (GSHandlerCheck, fltused, round, etc.), plus missing Win32 APIs (DuplicateHandle, GetCurrentThread, etc.)

Runtime.lib needs to be ported from Windows to UEFI to be usable.

(Cool project, btw! )

from efisharp.

Yep, this is missing C runtime (GSHandlerCheck, fltused, round, etc.), plus missing Win32 APIs (DuplicateHandle, GetCurrentThread, etc.)

Runtime.lib needs to be ported from Windows to UEFI to be usable.

(Cool project, btw! )

I did know about the Runtime.lib issues, I already added part of MathHelpers.cpp so I could cast float to ulong but going much further and adding functions like RhpNewArray proved a bit hard.
Weirdly, at one point I did have libcmt.lib errors so it was being used. I did check and I do not have /NODEFAULTLIB anymore so not sure why it disappeared.

from efisharp.

The updated compiler almost deals with all the errors in the first red image, all that is left is the unresolved floating point operations in MathHelpers.obj. The linker says it is the Runtime.lib version however so I worry that once I fix these errors I will get the grey error list again.

from efisharp.

It turns out I was mistaken and those errors were only shown because I forgot to include my version of MathHelpers.cpp. It would probably a good idea to deal with those functions at some point however as floating point support is still quite limited and even modulus is currently broken.
Also it turns out hyperv is only picky about adding file permissions to images in locations were questionable. Taking full ownership of the project folder before making EfiSharp.vhd means that hyperv will read it without first using icacls to give it access.

from efisharp.

I guess the v6 compiler uses exe now, even for efi binaries.

Changing its extension to efi does result in a useable image so it is fine either way.

from efisharp.