-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Native AOT smoke test #82
Add Native AOT smoke test #82
Conversation
Never been happier to see a test failure.
|
@@ -100,88 +100,3 @@ jobs: | |||
nameSuffix: All_Configurations | |||
buildArgs: -s clr.runtime+libs -c $(_BuildConfig) -allConfigurations | |||
|
|||
# |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joperezr The CI infrastructure in the NativeAOT branch is going to be a bit different from how CI is done in the runtime repo (we can't do AOT compilation on the Helix machines because they miss some big prerequisites, so we'll do the testing on the build machine - this should be similar how the current plan for iOS testing in the runtime repo will be).
Do you think it makes sense to try to share the runtimelab.yml file, or just make a new one to avoid constant merge conflicts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s ok to have another yml file if desired, but that will mean that we have to setup a whole new pipeline on AzDO for this branch so just keep thag in mind, since AzDO pipelines are tied to only one yml file. On the other hand, if you do decide to change runtimelab.yml to suit your needs, we could just ignore conflicts from that file and keep branch’s version always.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, you shouldn’t expect to get many conflicts as the idea is to have runtimelab.yml as stable as possible, which in fact was the whole reason we created that as opposed to using runtime.yml which gets changed much more frequently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I didn't know that extra yaml file would be work - I'll just keep this and we'll ignore conflicts in the future integrations.
@@ -7,53 +7,8 @@ parameters: | |||
|
|||
steps: | |||
# Build coreclr native test output | |||
- script: $(Build.SourcesDirectory)/src/coreclr/build-test$(scriptExt) skipstressdependencies skipmanaged skipgeneratelayout $(buildConfigUpper) ${{ parameters.archType }} | |||
displayName: Build native test components | |||
- script: $(Build.SourcesDirectory)/src/coreclr/build-test$(scriptExt) skipstressdependencies $(buildConfigUpper) ${{ parameters.archType }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will have conflict with #86. These scripts were just moved around dotnet/runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the heads up! Yeah, conflicts in infra/build seem inevitable - they churn a lot.
This reverts commit a236229.
@@ -55,7 +55,6 @@ The .NET Foundation licenses this file to you under the MIT license. | |||
|
|||
<ItemGroup> | |||
<NativeLibrary Include="$(IlcPath)/framework/libSystem.Native$(NativeLibraryExtension)" /> | |||
<NativeLibrary Include="$(IlcPath)/framework/libSystem.Globalization.Native$(NativeLibraryExtension)" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need this. We need to fix the build to start building it again.
cc @VSadov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering - Is this going to be used or just to make the build happy?
Libraries in coreclr hardcode "QCall" at the moment. AOT uses different libraries?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Native AOT needs a regular .a in the package. It does not need any tables with mapping, etc. The native linker that produces the final native AOT binary will take care of stitching everything together.
Libraries in coreclr hardcode "QCall"
"QCall" is hardcoded just for the System.Globalization.Native in coreclr. Everything else uses actual name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider out of scope for this pull request and disable testing on Linux?
Or is this as easy as adding Globalization.Native to CMakeLists.txt and treating DllImport("QCall")
same as the other libSystem
imports (i.e. have linker deal with it)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider out of scope for this pull request and disable testing on Linux?
I think so.
Seems Linux also has other problems. |
This reverts commit 582faad.
OK, this is now ready for review! I'll leave the Linux support pieces in place because they do work - it's just we need to fix Linux to be able to uncomment the test run. |
The tests are copied from the CoreRT repo without any changes. It's not all tests yet because there's some more issues. E.g. the reflection test is hitting something weird with SR/ResourceManager. We had to upgrade SR source generation to the one used in Arcade and it seems like there's still some work to do. |
@@ -23,5 +23,9 @@ source $scriptroot/eng/common/tools.sh | |||
InitializeDotNetCli true # Install | |||
__dotnetDir=${_InitializeDotNetCli} | |||
|
|||
# Temporarily make this dotnet more permanent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to send PR with this change to dotnet/runtime too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only needed because we don't publish ilc as a selfcontained app. Do you think it's still valuable in dotnet/runtime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that you have added this for your own convenience to make dotnet.sh
work on anything. Is it the case, or is this needed to make the CI work as well?
If this is for convenience, I think it would be useful in dotnet/runtime too.
If this is a temporary workaround to make CI work, it would be nice to have better comments on it that describe what it is for and what it would take to remove it.
@@ -52,7 +52,8 @@ public override bool GenerateDirectCall(string importModule, string methodName) | |||
methodName == "LoadLibraryExW" || | |||
methodName == "GetProcAddress" || | |||
methodName == "SetLastError" || | |||
methodName == "GetLastError") | |||
methodName == "GetLastError" || | |||
methodName == "LocalAlloc") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add LocalFree
here as well to make it symmetric? Also, GetProcessHeap
and HeapAlloc
do not need to be in the list now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
* Don't build createdump * We need mscorrc
Great, GitHub did the thing where it errors out during squash and merge and says you need to try again, but it actually merged, with a merge commit. I now have a theory that this happens if you push a new commit, don't wait for the UI to refresh, and hit squash and merge. |
For the |
We need STATIC library for NativeAOT. CoreCLR needs OBJECT library given how the build is put together today. Would we gain anything by building the STATIC library inside coreclr subset? The library would be otherwise unused within the coreclr subset. |
I think the eventual state will be that:
The above may take more than one change. To really "disappear" the Ultimately, the static libs can be transient and do not need to be installed, but we can do that for external consumers - i.e AOT By building with coreclr we are closer to this model. |
One advantage is that there is no possibility of Debug/Release mismatch. For example if we build native libraries in Libraries, then some common, and useful, configurations like "release clr; debug libs" will not be buildable on Windows. It is one of the reasons we do not have superhost on Windows. It is not the major issue perhaps, but it is an issue. |
This is the change I have in mind - dotnet/runtime#42166 |
If you change CoreCLR to be on the STATIC libs plan, I agree it starts to make more sense. There is still a problem with Mono. How does Mono fit in? Is Mono still going to build its own STATIC lib? |
The sources would stay in the same place, so Mono can continue building own static lib. I am not sure if the same lib binary could work for Mono or if the arrangement of build dependencies would allow to build a static lib just once. If that is the question. Globalization is a bit special. Since it is always embedded and as long as we do not have other uses we could use OBJECT lib. For other libs we have to build static, one way or another - as long as superhost builds in a separate partition and needs them.. |
I assume that AOT builds coreclr as a prerequisite - directly or because of dependency on libs. |
Michal added a new subset for the native aot so we can conveniently build just those parts for the day-to-day work on the project, without building the whole dotnet/runtime: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/eng/Subsets.props#L95 . The subsets can be sets of arbitrary build targets. It just takes extra plumbing to get the arbitrary locations wired up. |
This fixes an existing bug where a connection can be leaked if the library is cleaned up while there are any outstanding internal connections. The fix is to have the worker shut them down if there is no external owner when the worker's thread is stopped. The PR also disabled event validation tests on schannel, since they require the connection to succeed (which doesn't work on Azure Pipelines, because Schannel TLS 1.3 isn't supported yet).
This is expected to fail for now because the delegate test doesn't run. We need a LINQ expressions library that won't Reflection.Emit.
Just want to see what the CI will do.