-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[mono] Extend MonoAOTCompiler Task #70851
[mono] Extend MonoAOTCompiler Task #70851
Conversation
1acab5c
to
e6b41f2
Compare
0ae941b
to
c142358
Compare
c142358
to
765f3aa
Compare
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
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 your patience with the feedback, LGTM! 👍
69e7953
to
e6c6176
Compare
/azp run runtime-wasm |
Azure Pipelines successfully started running 1 pipeline(s). |
@@ -878,6 +936,12 @@ private bool PrecompileLibrary(PrecompileArguments args) | |||
bool copied = false; | |||
foreach (var proxyFile in args.ProxyFiles) | |||
{ | |||
if (!File.Exists(proxyFile.TempFile)) | |||
{ | |||
Log.LogError($"Precompile command succeeded, but can't find the expected temporary output file - {proxyFile.TempFile} for {assembly}.{Environment.NewLine}{output}"); |
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 check is causing some Android AOT builds to fail with:
C:\a\_work\1\s\bin\Release\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.0-ci.darc-main-c081764c-bbdd-4561-82bd-a59b76df22f3.71\targets\Microsoft.Android.Sdk.Aot.targets(91,5): Precompile command succeeded, but can't find the expected temporary output file - obj\Release\android-arm\aot\UnnamedProject.dll-llvm.o for C:\a\_work\1\a\TestRelease\06-28_05.09.49\temp\BuildBasicApplicationReleaseProfiledAotTrue\obj\Release\android-arm\linked\UnnamedProject.dll.
This started happening here: dotnet/android#7127
Here is the project with msbuild.binlog
inside:
BuildBasicApplicationReleaseProfiledAotTrue.zip
I think the file it's looking for doesn't actually exist:
obj\Release\android-arm\aot\UnnamedProject.dll-llvm.o
And this file is at:
obj\Release\android-arm\aot\armeabi-v7a\UnnamedProject\temp-llvm.o
Let me know if I need to change something in the Android workload, thanks!
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.
In the mono-aot-cross
command line you have ,llvm-outfile=obj\Release\android-arm\aot\UnnamedProject.dll-llvm.o
. Is this file not expected to be an output? I don't see it in the obj
directory.
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.
Full mono-aot-cross command:
[UnnamedProject.dll] Exec (with response file contents expanded) in C:\a\_work\1\a\TestRelease\06-28_05.16.51\temp\BuildBasicApplicationReleaseProfiledAotTrue: MONO_PATH=C:\a\_work\1\a\TestRelease\06-28_05.16.51\temp\BuildBasicApplicationReleaseProfiledAotTrue\obj\Release\android-arm\linked; MONO_ENV_OPTIONS= C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.NETCore.App.Runtime.AOT.win-x64.Cross.android-arm\7.0.0-preview.6.22322.7\Sdk\..\tools\mono-aot-cross.exe --verbose --debug
--llvm "
--aot=asmwriter,
temp-path=obj\Release\android-arm\aot\armeabi-v7a\UnnamedProject,
nodebug,
llvm-path=C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.NETCore.App.Runtime.AOT.win-x64.Cross.android-arm\7.0.0-preview.6.22322.7\Sdk\..\tools,
mtriple=armv7-linux-gnueabi,
tool-prefix=C:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.0-ci.darc-main-c081764c-bbdd-4561-82bd-a59b76df22f3.71\tools\binutils\bin\arm-linux-androideabi-,
outfile=obj\Release\android-arm\aot\UnnamedProject.dll.so,
llvm-outfile=obj\Release\android-arm\aot\UnnamedProject.dll-llvm.o,
ld-name=ld.CMD,
ld-flags=\"-LC:\a\_work\1\a\TestRelease\06-28_05.16.51\temp\SDK Ümläüts\sdk\ndk\24.0.8215888\toolchains\llvm\prebuilt\windows-x86_64\sysroot\usr\lib\arm-linux-androideabi\21\";\"-LC:\a\_work\1\s\xamarin-android\bin\Release\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.0-ci.darc-main-c081764c-bbdd-4561-82bd-a59b76df22f3.71\tools\binutils\bin\..\sysroot\usr\lib\arm-linux-androideabi\";\"C:\a\_work\1\a\TestRelease\06-28_05.16.51\temp\SDK Ümläüts\sdk\ndk\24.0.8215888\toolchains\llvm\prebuilt\windows-x86_64\sysroot\usr\lib\arm-linux-androideabi\21\libc.so\";\"C:\a\_work\1\a\TestRelease\06-28_05.16.51\temp\SDK Ümläüts\sdk\ndk\24.0.8215888\toolchains\llvm\prebuilt\windows-x86_64\sysroot\usr\lib\arm-linux-androideabi\21\libm.so\"
-s"
"obj\Release\android-arm\linked\UnnamedProject.dll"
- In that we have:
,outfile=obj\Release\android-arm\aot\UnnamedProject.dll.so
,llvm-outfile=obj\Release\android-arm\aot\UnnamedProject.dll-llvm.o
-
Should
obj\Release\android-arm\aot\UnnamedProject.dll-llvm.o
not be expected to exist? -
It gets added to the list of files at
string llvmObjectFile = Path.Combine(OutputDir, Path.ChangeExtension(assemblyFilename, ".dll-llvm.o")); -
because no cache file is being used,
proxy.TempFile
will be same asproxy.TargetFile
. -
Also,
aotAssembly.SetMetadata("LlvmObjectFile", proxyFile.TargetFile); - this suggests that the file is expected to exist
- if that's true, then I think maybe
mono-aot-cross
failed but didn't return a non-zero error code?
-
in the output I see many
LLVM failed
messages, are those expected? -
We do delete the temp file (in this case == target file):
File.Delete(TempFile); - but this shouldn't be getting hit.
(I'll anyway prep a PR for fixing some temp file stuff)
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.
#71411 should remove the error. But IIUC, in this case if the dll-llvm.o
file doesn't exist, then it will fail outside this task.
Maybe we should add a check to ensure that all the "expected" output files actually exist after running mono-aot-cross
. Unless you think there is some reason not to.
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'm honestly not sure about any of the intermediate files that are created here. We only really use the .so
files that exist at the end, and those appear to exist? (Back when this task completed successfully)
We also don't use EnableLLVM=true
by default, so there could be an issue or two when that is enabled.
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.
@jonathanpeppers aotAssembly.SetMetadata("LlvmObjectFile", proxyFile.TargetFile);
- this isn't used?
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.
No, we don't set this metadata at all. I think it's because we use the .so
files as-is -- and don't currently do anything extra.
There were some ideas about using a native linker to do extra things (which would need the .o
files) -- but we haven't implemented that yet.
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.
@akoeplinger please help out with this if ankit's fix doesn't solve the issue
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.
The code indicates that it is expecting an output file by creating this ProxyFile
object:
runtime/src/tasks/AotCompilerTask/MonoAOTCompiler.cs
Lines 784 to 785 in cc3ac1b
string llvmObjectFile = Path.Combine(OutputDir, Path.ChangeExtension(assemblyFilename, ".dll-llvm.o")); | |
ProxyFile proxyFile = _cache.NewFile(llvmObjectFile); |
So, from correctness pov it would be completely fair to check that the expected output file exists after mono-aot-cross
has run. But in this case it seems that:
- the file is never generated
- even though we have
aotAssembly.SetMetadata("LlvmObjectFile", proxyFile.TargetFile);
, it is not being used else I would expect the task user/caller to break since the file is not generated.
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 see it being used at:
runtime/src/tasks/AppleAppBuilder/AppleAppBuilder.cs
Lines 203 to 205 in 5877e8b
// use AOT files if available | |
var obj = file.GetMetadata("AssemblerFile"); | |
var llvmObj = file.GetMetadata("LlvmObjectFile"); |
runtime/src/tasks/AndroidAppBuilder/ApkBuilder.cs
Lines 141 to 143 in 5877e8b
// use AOT files if available | |
var obj = file.GetMetadata("AssemblerFile"); | |
var llvmObj = file.GetMetadata("LlvmObjectFile"); |
I'll make this file optional (for the existence check), and check for all other files.
…71411) * MonoAOTCompilerTask: Don't check for temp file if cache is disabled Prompted by #70851 (comment) * Emit a message when deleting tmp files
Part of #69512
In effort to make the dotnet-pgo based Profiled AOT story on mono more seamless (i.e. less steps for users), the MonoAOTCompiler itself can call a dotnet-pgo executable and inherently process a
.nettrace
, and ultimately feeding into #70194.This PR makes the following changes:
a) Allows for cache usage to avoid generating the same .mibc from the same source .nettrace
Example workflow with Desktop mono HelloWorld sample
Generating a .nettrace
make run
DOTNET_DiagnosticPorts="~/myport,suspend" <path-to-HelloWorld-executable> (e.g. ../../../../artifacts/bin/HelloWorld/arm64/Release/osx-arm64/publish/HelloWorld)
in a separate tab
dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:0x1F000080018:5 --diagnostic-port ~/myport --output <output .nettrace file>
Utilizing the .nettrace
In the makefile
Set
AOT?=true
Set
NET_TRACE_PATH=
to the output .nettrace fileSet
PGO_BINARY_PATH=
to the dotnet-pgo executablemake run