-
Notifications
You must be signed in to change notification settings - Fork 528
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
Certain projects are failing to build with AOT and LLVM enabled against d15-6 on Windows #1182
Comments
Log output for the AOT task looks incomplete. Could you manually run the AOT commands as stated in the log files and provide the output? |
Could you upload the obj/Release directory somewhere ? |
also seeing this on my automated build machine after updating to VS 15.6 |
Another item to note is that this does not occur when the project only supports @vargaz I've uploaded the intermediate output here. @kumpera Is there a way for me to get more output aside from
Results in llc.exe aborting. VS also hangs and then reboots if I reproduce this from within the IDE:
|
I can't reproduce on osx with the files from the Release directory, so it might be a problem with the llc executable itself, not with the input to it. |
The same file causes the llc.exe from 15-6 to fail, while the llc.exe from 15-5 works fine. The llvm version in 15-5/15-6 appears to be the same, so it might be a change in the way llc.exe is compiled. |
@vargaz: The MXE version was bumped between d15-5 and d15-6. Perhaps this is an MXE and/or compiler bug? |
@dellis1972: Don't we have any tests which try building with AOT+LLVM enabled? If we don't, please add one. :-) |
Thats most likely the culprit. |
Is this "c000005" rendition of the problem easy to setup and run on Windows? |
ps: can someone teach me how to run/repro it? |
@jonpryor we do but under certain conditions they are ignored, See https://github.com/xamarin/xamarin-android/blob/master/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest.cs#L348 |
@dellis1972: Thank you. Running the cross-compiler tests only when the cross-compilers exist should be fine -- it means they'll be skipped on default PR builds but executed on master builds. Now I have to wonder why ApiDemo fails but our default project doesn't fail... Must be something in the IL? |
@jonpryor this is also a windows specific failure, I am not sure if the msbuild suite is running everything on Windows quite yet? |
Tried rebasing our mxe based on mxe upstream master, and compiling llvm using that version, but the resulting llc.exe fails the same way, both the 32 bit and the 64 bit version. |
@pjcollins: That is correct: our VSTS+xamarin-android build is not yet running MSBuild Task unit tests. |
@vargaz: so we either figure out what's wrong in MXE and fix it, or we revert to the last used MXE -- which means we cannot possibly build with newer Xcode.app versions. :-/ (I think -- but have not yet had a chance to verify -- that a newer MXE is also required in order to build a newer libzip; see PR #863 and 91b3430, which reverted PR #863.) |
Tried compiling llvm with -O2 and -O1 too, the crash still happens. |
"Good news", compiling llvm on osx using the gcc from homebrew can be used to reproduce the crash, so it happens on osx too when using gcc. |
llvm testcase:
|
The stack trace looks like this: frame #0: 0x00000001004eb117 llc`llvm::MachineInstr::addOperand(llvm::MachineFunction&, llvm::MachineOperand const&) + 23
and the assembly: Basically rdi, which should contain a MachineInstr& is set to 0. |
A possible fix to this problem is to revert to the old version of mxe, and cherry-pick the neccessary changes instead of merging to mxe master. |
@vargaz also, does it crash when you build llvm with -O0? If no then perhaps the fix is to use one of the |
… optimizer problem. dotnet/android#1182.
Added a workaround in: |
… optimizer problem. dotnet/android#1182.
Cherry-picked to d15-6 via llvm/d15-6/b918f466 and 73c16c0. monodroid bump + build pending once the Jenkins xamarin-android-d15-6 job is complete. |
has this been merged into VS15.5.5 or is this going to be in VS15.6? |
@JKennedy24 are you able to reproduce this issue against a VS15.5 variant? From what I have seen, this issue was only introduced in 15.6 and will be fixed before the final 15.6 stable release. |
@pjcollins In that case I may have confused this issue with a different one I am seeing. I am seeing this issue: https://developercommunity.visualstudio.com/content/problem/161766/xamarin-android-ci-build-fails-with-invalidoperati.html And pressumed this was it, but actually I think it is more of an issue with msbuild |
Commit list for mono/llvm: * mono/llvm@f80899cb3eb [mono] respect hardfloat/softloat setting in ARM ABI (mono#16) * mono/llvm@f80899cb3eb (HEAD -> master, origin/master) [mono] respect hardfloat/softloat setting in ARM ABI (mono#16) * mono/llvm@37e14bd72e6 Fix the mono calling convention on arm64+linux. * mono/llvm@acb33f3436e Pack 32bits llc, opt and llvm-dis in archive as well * mono/llvm@9b92b4b8760 Merge pull request mono#14 from lateralusX/lateralusX/build-llvm-windows-x64 * mono/llvm@e2ae3309b0c Fixes Mono LLVM usage on Windows x64. * mono/llvm@384caa9849a Build LLVM Windows x64 using CMake + VS2015 or VS2017. * mono/llvm@0b3cb8ac12c Emit an LSDA for methods without landing pads too since we need the information about the 'this' register.fbbfbae4fea [ci] Enable x86/amd64 backends. (mono#9) * mono/llvm@8e14f6654ad Add 3.9 Packaging Scripts and Cross Compilation Support (mono#8) * mono/llvm@bdb3a116dbf Change some code slighly in AArch64InstrInfo.cpp to work around a gcc optimizer problem. dotnet/android#1182. * mono/llvm@3b82b3c9041 [ci] Really compile the 32 bit llvm as 32 bit. * mono/llvm@73c983a02a2 [ci] Distribute 32 bit llvm-config. * mono/llvm@0692a5ea231 [ci] Install 64-bit binaries into usr64 for consistency. * mono/llvm@804c869e6b5 [ci] Fix 32 bit build.8dfa8ebfc25 [ci] Compile a 32 bit version of llvm as well.07582cba7cc [ci] Package llvm-config as well. * mono/llvm@a9cfb50e5af [ci] Fix an rm statement which can fail. * mono/llvm@a21fcae962a Add a jenkins build script. * mono/llvm@21492ec92e2 Revert "Add a workaround to the problem where the amd64 JIT would make all calls as register indirect." * mono/llvm@6aa74ae5723 Fix a regression caused by: * mono/llvm@5056b9f2bcb Rename the temp labels used by DwarfMonoException so they don't collide with the ones used by the GNU EH frame. * mono/llvm@975e3a69030 Align the size of the Mono EH table to 8 to prevent an ld assertion. Fixes #55553. * mono/llvm@dbb6fdffdeb [arm] Handle CallingConv::Mono in getEffectiveCallingConv (), previously it would be handled by the default branch, which would fall through to the next switch case because llvm_unreachable() was a noop in release builds. * mono/llvm@5b94bc7097e Avoid making the EH table symbol global, its not needed any more. * mono/llvm@8b1520c8aae Merge pull request mono#6 from Xaltotun/feature/cmake_build * mono/llvm@8d00fd38456 Fixed MONO_API_VERSION define for the cmake build. For #cmakedefine to work, the variable needs to be declared in the cmake script otherwise it will be commented out in the generated file. * mono/llvm@73df95d02d3 Merge pull request mono#5 from alexanderkyte/mastere * mono/llvm@51cd999c98 [mono] Fix MONO_API_VERSION usage with cmake Diff: mono/llvm@9f79399...f80899c
* [llvm] bump for armhf callingconv fix Commit list for mono/llvm: * mono/llvm@f80899cb3eb [mono] respect hardfloat/softloat setting in ARM ABI (#16) * mono/llvm@f80899cb3eb (HEAD -> master, origin/master) [mono] respect hardfloat/softloat setting in ARM ABI (#16) * mono/llvm@37e14bd72e6 Fix the mono calling convention on arm64+linux. * mono/llvm@acb33f3436e Pack 32bits llc, opt and llvm-dis in archive as well * mono/llvm@9b92b4b8760 Merge pull request #14 from lateralusX/lateralusX/build-llvm-windows-x64 * mono/llvm@e2ae3309b0c Fixes Mono LLVM usage on Windows x64. * mono/llvm@384caa9849a Build LLVM Windows x64 using CMake + VS2015 or VS2017. * mono/llvm@0b3cb8ac12c Emit an LSDA for methods without landing pads too since we need the information about the 'this' register.fbbfbae4fea [ci] Enable x86/amd64 backends. (#9) * mono/llvm@8e14f6654ad Add 3.9 Packaging Scripts and Cross Compilation Support (#8) * mono/llvm@bdb3a116dbf Change some code slighly in AArch64InstrInfo.cpp to work around a gcc optimizer problem. dotnet/android#1182. * mono/llvm@3b82b3c9041 [ci] Really compile the 32 bit llvm as 32 bit. * mono/llvm@73c983a02a2 [ci] Distribute 32 bit llvm-config. * mono/llvm@0692a5ea231 [ci] Install 64-bit binaries into usr64 for consistency. * mono/llvm@804c869e6b5 [ci] Fix 32 bit build.8dfa8ebfc25 [ci] Compile a 32 bit version of llvm as well.07582cba7cc [ci] Package llvm-config as well. * mono/llvm@a9cfb50e5af [ci] Fix an rm statement which can fail. * mono/llvm@a21fcae962a Add a jenkins build script. * mono/llvm@21492ec92e2 Revert "Add a workaround to the problem where the amd64 JIT would make all calls as register indirect." * mono/llvm@6aa74ae5723 Fix a regression caused by: * mono/llvm@5056b9f2bcb Rename the temp labels used by DwarfMonoException so they don't collide with the ones used by the GNU EH frame. * mono/llvm@975e3a69030 Align the size of the Mono EH table to 8 to prevent an ld assertion. Fixes #55553. * mono/llvm@dbb6fdffdeb [arm] Handle CallingConv::Mono in getEffectiveCallingConv (), previously it would be handled by the default branch, which would fall through to the next switch case because llvm_unreachable() was a noop in release builds. * mono/llvm@5b94bc7097e Avoid making the EH table symbol global, its not needed any more. * mono/llvm@8b1520c8aae Merge pull request #6 from Xaltotun/feature/cmake_build * mono/llvm@8d00fd38456 Fixed MONO_API_VERSION define for the cmake build. For #cmakedefine to work, the variable needs to be declared in the cmake script otherwise it will be commented out in the generated file. * mono/llvm@73df95d02d3 Merge pull request #5 from alexanderkyte/mastere * mono/llvm@51cd999c98 [mono] Fix MONO_API_VERSION usage with cmake Diff: mono/llvm@9f79399...f80899c * [arm64] Pass small stack args correctly on linux. Fixes pinvoke.exe with llvm+full aot. Backport of #10674.
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1290584 Fixes: dotnet#5710 Changes: xamarin/monodroid@75cf1a2...3a05726 * xamarin/monodroid@3a05726b8: [Xamarin.Android.Build.Tasks] Fix the MAX_COMMAND adb Error. (dotnet#1182) * xamarin/monodroid@83de4b43c: [Xamarin.Android.Build.Tasks] Support FastDev for System Apps (dotnet#1177) * xamarin/monodroid@02f19e057: Bump to xamarin/android-sdk-installer@6bf8527 (dotnet#1176)
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1290584 Fixes: #5710 Changes: xamarin/monodroid@75cf1a2...3a05726 * xamarin/monodroid@3a05726b8: [Xamarin.Android.Build.Tasks] Fix the MAX_COMMAND adb Error. (#1182) * xamarin/monodroid@83de4b43c: [Xamarin.Android.Build.Tasks] Support FastDev for System Apps (#1177) * xamarin/monodroid@02f19e057: Bump to xamarin/android-sdk-installer@6bf8527 (#1176)
I'm seeing a new failure on Windows when compiling certain projects with both AOT and LLVM. The same error does not reproduce for me on macOS, and appears to be newly introduced in 15.6.
Steps to Reproduce
Expected Behavior
The project builds successfully with AOT and LLVM enabled.
Actual Behavior
Version Information
https://gist.github.com/pjcollins/842d3a55d49841a4fa955cd403af1549
Android NDK 15.2.4203891
Log File
http://xqa.blob.core.windows.net/gist/report-7d4d56fee1504d14818b0cef6538694e.txt
The text was updated successfully, but these errors were encountered: