WASM (LLVM): Assertion failure when building on OSX

[KodrAus]

Hi :wave:

I have the following program:

using System;

namespace NetApp
{
    class Program
    {
        static int Main()
        {
            return 0;
        }
    }
}

Right now we can't build wasm on OSX (because of #6827), but if I patch in my own working 6.x build of libLLVM.dylib (as described here) then I run into a different issue.

Running:

$ ilc obj/release/netcoreapp2.1/osx-x64/native/netapp.ilc.rsp

where netapp.ilc.rsp looks something like this:

obj/release/netcoreapp2.1/osx-x64/netapp.dll
-o:obj/release/netcoreapp2.1/osx-x64/native/netapp.bc
-r:<lots of stuff>
--wasm
-O
--initassembly:System.Private.CoreLib
--initassembly:System.Private.DeveloperExperience.Console
--initassembly:System.Private.StackTraceMetadata
--initassembly:System.Private.TypeLoader
--initassembly:System.Private.Reflection.Execution
--initassembly:System.Private.Interop
--completetypemetadata
--stacktracedata
--rootallapplicationassemblies

results in:

Assertion failed: (C->getType()->isIntOrIntVectorTy() && Ty->isIntOrIntVectorTy() && "Invalid integer cast"), function CreateIntegerCast, file /Users/user/dev/dotnet/llvm/lib/IR/Instructions.cpp, line 2731.
Stop reason: signal SIGABRT

with some extra info coming out of lldb:

clrstack
OS Thread Id: 0x2d7b1c (1)
        Child SP               IP Call Site
00007FFEEFBF4A70 00007fff7a4db23e [InlinedCallFrame: 00007ffeefbf4a70] LLVMSharp.LLVM.BuildIntCast(LLVMSharp.LLVMBuilderRef, LLVMSharp.LLVMValueRef, LLVMSharp.LLVMTypeRef, System.String)
00007FFEEFBF4A70 000000010a8879e1 [InlinedCallFrame: 00007ffeefbf4a70] LLVMSharp.LLVM.BuildIntCast(LLVMSharp.LLVMBuilderRef, LLVMSharp.LLVMValueRef, LLVMSharp.LLVMTypeRef, System.String)
00007FFEEFBF4A60 000000010A8879E1 DomainBoundILStubClass.IL_STUB_PInvoke(LLVMSharp.LLVMBuilderRef, LLVMSharp.LLVMValueRef, LLVMSharp.LLVMTypeRef, System.String)
00007FFEEFBF4B40 000000010A897746 Internal.IL.ILImporter.ThrowIfNull(LLVMSharp.LLVMValueRef) [/Users/user/dev/dotnet/corert/src/ILCompiler.WebAssembly/src/CodeGen/ILToWebAssemblyImporter.cs @ 3187]
00007FFEEFBF5130 000000010A896CE6 Internal.IL.ILImporter.ImportLoadLength() [/Users/user/dev/dotnet/corert/src/ILCompiler.WebAssembly/src/CodeGen/ILToWebAssemblyImporter.cs @ 3530]
00007FFEEFBF52B0 000000010A87836F Internal.IL.ILImporter.ImportBasicBlock(BasicBlock) [/Users/user/dev/dotnet/corert/src/Common/src/TypeSystem/IL/ILImporter.cs @ 667]
00007FFEEFBF5720 000000010A877147 Internal.IL.ILImporter.ImportBasicBlocks() [/Users/user/dev/dotnet/corert/src/Common/src/TypeSystem/IL/ILImporter.cs @ 304]
00007FFEEFBF5750 000000010A873AE9 Internal.IL.ILImporter.Import() [/Users/user/dev/dotnet/corert/src/ILCompiler.WebAssembly/src/CodeGen/ILToWebAssemblyImporter.cs @ 152]
00007FFEEFBF58F0 000000010A7470FF Internal.IL.ILImporter.CompileMethod(ILCompiler.WebAssemblyCodegenCompilation, ILCompiler.DependencyAnalysis.WebAssemblyMethodCodeNode) [/Users/user/dev/dotnet/corert/src/ILCompiler.WebAssembly/src/CodeGen/ILToWebAssemblyImporter_Statics.cs @ 86]
00007FFEEFBF5A80 000000010A746CB6 ILCompiler.WebAssemblyCodegenCompilation.ComputeDependencyNodeDependencies(System.Collections.Generic.List`1<ILCompiler.DependencyAnalysisFramework.DependencyNodeCore`1<ILCompiler.DependencyAnalysis.NodeFactory>>) [/Users/user/dev/dotnet/corert/src/ILCompiler.WebAssembly/src/Compiler/WebAssemblyCodegenCompilation.cs @ 61]
00007FFEEFBF5B00 000000010A7451BC ILCompiler.DependencyAnalysisFramework.DependencyAnalyzer`2[[ILCompiler.DependencyAnalysisFramework.NoLogStrategy`1[[System.__Canon, System.Private.CoreLib]], ILCompiler.DependencyAnalysisFramework],[System.__Canon, System.Private.CoreLib]].ComputeDependencies(System.Collections.Generic.List`1<ILCompiler.DependencyAnalysisFramework.DependencyNodeCore`1<System.__Canon>>) [/Users/user/dev/dotnet/corert/src/ILCompiler.DependencyAnalysisFramework/src/DependencyAnalyzer.cs @ 139]
00007FFEEFBF5B30 000000010A71D7B3 ILCompiler.DependencyAnalysisFramework.DependencyAnalyzer`2[[ILCompiler.DependencyAnalysisFramework.NoLogStrategy`1[[System.__Canon, System.Private.CoreLib]], ILCompiler.DependencyAnalysisFramework],[System.__Canon, System.Private.CoreLib]].ComputeMarkedNodes() [/Users/user/dev/dotnet/corert/src/ILCompiler.DependencyAnalysisFramework/src/DependencyAnalyzer.cs @ 262]
00007FFEEFBF5C20 000000010A71D69E ILCompiler.WebAssemblyCodegenCompilation.CompileInternal(System.String, ILCompiler.ObjectDumper) [/Users/user/dev/dotnet/corert/src/ILCompiler.WebAssembly/src/Compiler/WebAssemblyCodegenCompilation.cs @ 50]
00007FFEEFBF5C80 000000010A71D47E ILCompiler.Compilation.ILCompiler.ICompilation.Compile(System.String, ILCompiler.ObjectDumper) [/Users/user/dev/dotnet/corert/src/ILCompiler.Compiler/src/Compiler/Compilation.cs @ 387]
00007FFEEFBF5CD0 00000001099C67E1 ILCompiler.Program.Run(System.String[]) [/Users/user/dev/dotnet/corert/src/ILCompiler/src/Program.cs @ 573]
00007FFEEFBF6790 00000001099C16F6 ILCompiler.Program.Main(System.String[]) [/Users/user/dev/dotnet/corert/src/ILCompiler/src/Program.cs @ 729]
00007FFEEFBF6AF8 0000000102c877e7 [GCFrame: 00007ffeefbf6af8] 
00007FFEEFBF6EA0 0000000102c877e7 [GCFrame: 00007ffeefbf6ea0] 

print C->getType()->ID
(llvm::Type::TypeID) $6 = PointerTyID
print Ty->ID
(llvm::Type::TypeID) $7 = PointerTyID

The culprit seems to be this operation, where llvm doesn't consider those pointer types to be valid to cast to.

[yowl]

In that line you reference, if you change LLVMTypeRef.Int8Type to LLVMTypeRef.Int32Type does that fix it?

[yowl]

Actually thats not a good idea as it wont match the signature of RhNewObject.

[yowl]

@KodrAus do you have a v6 package or dll that I can reference on Windows to see if I can replicate the problem here?

[KodrAus]

@yowl As far as I know libLLVM v6 on Windows is ok, is that not the case? I do have libLLVM builds being produced as artifacts here, but haven't gotten as far as testing whether the built library actually works yet, so they may be even more broken at the moment :)

[yowl]

@KodrAus the project references 5.0.0:

    <PackageReference Include="LLVMSharp">
      <Version>5.0.0</Version>
    </PackageReference>  

Which I understand is libLLVM 5.0.0. I could be wrong as the dll seems to have no version information

[yowl]

I dont think I have permission to get those artifacts from AzureDevops

[KodrAus]

Which I understand is libLLVM 5.0.0. I could be wrong as the dll seems to have no version information

Ah, it seems to be explicitly pulling in libLLVM 6.0.0.

I dont think I have permission to get those artifacts from AzureDevops

Oh thanks for the heads up! I hadn't realised Azure Pipelines would throw a login gate in front of those artifacts. I guess I'd better set up a feed to publish to.

[yowl]

@KodrAus right you are, missed that. BuildAlloca returns a pointer so maybe that BuildIntCast can just be dropped, I don't really get why its there.

[KodrAus]

I think that's pretty much what I did to unblock myself locally:

- var resultAddress = LLVM.BuildIntCast(builder, LLVM.BuildAlloca(builder, LLVM.Int32Type(), "resultAddress"), LLVM.PointerType(LLVMTypeRef.Int8Type(), 0), "castResultAddress");
+ var resultAddress = LLVM.BuildAlloca(builder, LLVM.Int8Type(), "resultAddress");

I wasn't sure if that was actually correct though. At least LLVM seemed ok with it.

[yowl]

Exception handling is something I'm trying to get working and when it is then we can create a test for the null ref handling. Until then it seems reasonable as you have it.