Add wrappers for support functions about inkwell HOT 5 OPEN

Other support functions requiring callbacks and/or void pointers:

• LLVMAddSymbol:
• LLVMSearchForAddressOfSymbol:
• LLVMLoadLibraryPermanently: 355a238
• LLVMParseCommandLineOptions:
• LLVMInstallFatalErrorHandler: f9902c6
• LLVMContextSetDiagnosticHandler
• LLVMContextSetYieldCallback
• LLVMGetDiagInfoDescription
• LLVMGetDiagInfoSeverity

from inkwell.

Adding a support module is a good idea. I already started a couple supporty methods in lib.rs (even though they don't come from llvm_sys' support.rs), so those should probably get moved.

I really want Inkwell to be as safe as possible, unless there's absolutely nothing we can do (see ExecutionEngine.get_function_address() for example). I think for a lot of these support methods that take a void pointer, we should be able to research what types of data is generally used in C/++, and provide a safe wrapper for those data types and allow them to be passed into these methods and turn them into void pointers behind the scenes as needed. (Though I'm not familiar with your example functions in particular, so I'm just speculating) What exactly are you trying to do with these methods?

from inkwell.

I'm working on add_symbol right now, and actually got it working! However, there is a bug when running all tests.

I think I'm having an LLVM bug here, and not an Inkwell / Rust bug.

Basically, I can add one symbol, but once an EE has been created, adding other symbols does not register them for resolution. Really weird issue.

from inkwell.

Alright, add_symbol has a bug when it is used more than once in a single process, but add_global_mapping DOES work! I'm gonna push a new commit.

In any case, is there a reason why tests.rs exists? With this file, every test is passed twice.

from inkwell.

Oh, interesting! I thought tests.rs was needed, like a mod.rs. I'll remove it in my next commit to master since it might break code coverage which looks for the tests binary. Thanks!

from inkwell.