[NativeAOT] Add ability to generate library and exe entry points#81873
[NativeAOT] Add ability to generate library and exe entry points#81873MichalStrehovsky merged 7 commits intodotnet:mainfrom
Conversation
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsThis PR adds a new flag to ILC, The use case for this is to allow calling It was not clear to me how to fit this into the larger NativeAot build system. Should this sort of use be thought of a "a static library that also has a Lastly, I added an example of what the build integration could looks like for the "an executable that splits its initialization into two parts" case, along with test. This can be reverted if it's not the right direction.
|
MichalStrehovsky
left a comment
There was a problem hiding this comment.
Looks good otherwise, thanks!
src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets
Outdated
Show resolved
Hide resolved
A coding error is more likely to run the Module Initializer twice than the cctor.
And fix some spelling in the variable name.
And change values that are added up so they are not multiples of each other
|
The (Build CoreCLR Tools Unit Tests linux x64 checked) failure is real. Otherwise looks good to merge, thanks! |
|
LGTM as well, thank you @AustinWise very much! Let me know if you need help fixing the remaining test failure. As a follow-up, we should also update the documentation here: https://github.com/dotnet/samples/blob/main/core/nativeaot/NativeLibrary/README.md |
|
Opps, I missed that test. It should be fixed now.
Sure, I can follow up with a sample based on the unit test. |
This PR adds a new flag to ILC,
--split-exe-initalization. The flag splits the initialization that is normally done for executable into two parts. The__managed__Startupfunction runs classlib and module initializers. The__managed__Mainfunction performs the remaining initialization and executes the entry-point of the managed application.The use case for this is to allow calling
UnamanagedCallersOnlyfunctions before the managedmainfunction. Running on iOS is the first use case for this feature (#80905).It was not clear to me how to fit this into the larger NativeAot build system. Should this be thought of as "a static library that also has a
__managed__Maincompiled in" or as "an executable that splits its initialization into two parts"? So I added support to ILC for both cases: compiling with the--nativelibflag and without it.Lastly, I added some build integration the "an executable that splits its initialization into two parts" case, along with test. The idea is the user sets the
CustomNativeMainproperty in their project. They are then responsible for providing aNativeLibraryitem pointing to an object file containing their nativemainfunction. At runtime, when they call their first managed function, NativeAOT initialization will run. This includes calling__managed__Main, so the user cannot forget to initialize the runtime.Related issues: #81097 #77957