LLVMDIBuilder missing from NuGet library

[morganbr]

Calls into DIBuilder, such as LLVM.NewDIBuilder fail because they're not exposed from the build of libLLVM in the matched NuGet package. This appears to be the case in both 3.9.1 and 5.0.

[mjsabby]

Yup, they are not officially part of the bindings so we have to make a special addition which looks like in the last builds got clobbered.

I'll get to this tomorrow. I'll do it for 4.0 and 5.0.

[ice1000]

I'll get to this tomorrow.

Cough cough 😜

[morganbr]

@mjsabby , might you have any suggestions on workarounds? We're starting to generate more complex code using LLVMSharp in https://github.com/dotnet/corert and it might be nice to start generating debug data before too much longer.

[mjsabby]

@morganbr sorry for the delay. Do you have a platform where you'd like this sooner? Like maybe windows?

[morganbr]

@mjsabby, for CoreRT, we're currently using 3.9.1 on Windows. If 5.0 on Windows works with Emscripten, we could try that too.

[morganbr]

@mjsabby, is there anything we could do to help out with this?

[ice1000]

😭 I want a write access, so I can update the LLVM demos

[morganbr]

@mjsabby, is the change needed here to just add the functions to the .def file and then rebuild libllvm.dll? If so, I'm happy to add a bunch of functions to the .def file.

[mjsabby]

@morganbr a little bit more than that, but essentially yes. The problem is DIBuilder changes need to be pushed into this branch.

Also, do you still need it for LLVM 4.0?

[kaby76]

DIBuilder was changed in the last month on the master branch of LLVM, and it's still being changed as of yesterday. Those changes came out after version 6.0 of LLVM. I don't see them being merged into the Jul '18 release 6.0.1, but probably the Sep '18 release v7.0. However, I did try out the line debug information API parts, and it works. There is now a way to create "context" for LLVMDIBuilderCreateDebugLocation, i.e., using LLVMDIBuilderCreateFunction, DIBuilderCreateSubroutineType, LLVMDIBuilderCreateLexicalBlock. There is, of course, no doc or examples on how to use that API, and so took a lot of trial and error to figure it out. I haven't tried out the variable API.

[morganbr]

@mjsabby, it looks like Emscripten just released a 5.0 version, so we could probably move to that if we needed to, but we're still currently using 4.0.

[mjsabby]

@morganbr I've started in earnest with 5.0 so if you could move there I'll be done there sooner.

[morganbr]

@mjsabby, I tested the 6.0.0-beta1 libllvm DIBuilder with llvmsharp 5.0.0 (Emscripten just shipped a LLVM 6 version, so I'm trying with that). The functions are there, but every function other than LLVM.NewDIBuilder hits an access violation. Is there a combination of libllvm and llvmsharp that should work?

[mjsabby]

@morganbr can you tell me what DIBuilder functions you need? I'll verify them as I rebuild the final nuget package.

[morganbr]

@mjsabby, I don't have the complete list since I haven't been able to build the functionality, but my best guesses would be something like this tutorial. We'd really like to at least have source line mapping work, eventually followed by local variable inspection. If you'd like me to play with a pre-release version, let me know and I'll give it a shot.

Needed for all debug info:

• NewDIBuilder
• DIBuilderFinalize
• DIBuilderCreateCompilerUnit
• DIBuilderDestroy (?)

Source line mapping:

• DIBuilderCreateFunction
• DIBuilderCreateFile
• DIBuilderCreateLexicalBlock
• DIBuilderCreateBasicType
• DIBuilderCreatePointerType
• DIBuilderCreateStructType
• DIBuilderCreateArrayType
• DIBuilderCreateSubroutineType
• SetCurrentDebugLocation
• SetCurrentDebugLocation2

Local variables:

• DIBuilderCreateLocalVariable
• DIBuilderInsertDeclareAtEnd
• DIBuilderInsertValueAtEnd

[mjsabby]

@morganbr Yeah these functions aren't available in the LLVM 6.0 upstream and I was trying to accommodate them myself, but that's not going well as LLVM moves way too quickly.

However, most of these are available in the latest unreleased LLVM, so I'll work on making an LLVM-7.0.0-pre1 package or something that has all these from upstream.

Is that even useful? I'm not sure how you integrate with emscripten. Do you need to use the same LLVM version as emscripten? Or as long as there are no changes to the LLVM IR, either encoded as bitcode or semantics etc. you can tolerate the changes?

[morganbr]

@mjsabby, I dug further into those functions. Everything we need is in 6.0 and the changes you already merged to match the 6.0 surface area probably fix the problems we're hitting. I think if you did a release of the llvmSharp package as-is (tied to the preview 6.0 libllvm), it would work for us.

The way to think about emscripten is that it's the WebAssembly LLVM linker. It can generally tolerate versions of LLVM bitcode older than it is, but not newer ones.