<div dir="ltr">Hi David,<div><br></div><div>I'm happy to review and accept improvements to the MCJIT APIs, but have you checked out the ORC C bindings (llvm/include/llvm-c/OrcCBindings.h) ?</div><div><br></div><div>The ORC bindings are relatively new. They're implemented on top of the ORC JIT library, which is a modular re-implementation of the MCJIT concept. Being new the bindings are fairly bare-bones at the moment, but I think they represent a good opportunity for us to re-think our JIT C API design in light of our experiences with MCJIT. I'll be doing the best I can with them, time permitting, but I'm not a client of the C API, and I'd certainly appreciate input from people who have used the existing API and who care about C API quality in general.</div><div><br></div><div>To reach feature parity with MCJIT's C API we'd need to plumb through support for custom memory managers and constructor and destructor execution (all of which are already supported by the underlying implementation). I don't think this plumbing would take too much work though. Notably, though I don't know whether this will be of any use to you personally, the ORC C APIs already support features that MCJIT is missing, such as lazy compilation.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 3:44 PM, David Herberth via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dav1d added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D16188#327370" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16188#327370</a>, @joker.eph wrote:<br>
<br>
> It is not clear to me why LLVMGetPointerToGlobal calls it but not LLVMGetGlobalValueAddress (or LLVMAddGlobalMapping or ...)<br>
<br>
<br>
</span>As I mentioned in the Issue (<a href="https://llvm.org/bugs/show_bug.cgi?id=24028" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=24028</a>), I am not happy with the C-API, stuff is missing (less and less with every new version, yay!), stuff happens implicitly without being mentioned (like finalizeObject). Changing the API now will break a lot of code, even if you only want to add a function to call finalizeObject explicitly (which is btw marked with a 'TODO rename me') and make it more consistent (add the function and remove the implicit calls).<br>
<br>
I am not sure how far you want to go with breaking the API. In my opinion a 'dumb' binding which simply only exposes the functionality of C++ to C would be the best *but* this would break existing code in a really bad manner (LLVMRunFunction suddenly segfaults for no obvious reason).<br>
<br>
This patch only focuses on the problem I ran into, the patch could be extended to call finalizeObject before every method call which requires a finalized object, but I don't think this is a good solution. If you want me to I can (probably, if I figure out how to with phabricator) update the patch to call finalizeObject on all the other functions which require a finalized object.<br>
<br>
PS: My current workaround:<br>
I have an empty function in my module, so before calling the constructors I run the function:<br>
<br>
// workaround which calls ee->finalizeObjects, which makes<br>
// LLVMRunStaticConstructors not segfault<br>
LLVMDisposeGenericValue(LLVMRunFunction(ee, "vmain", []));<br>
LLVMRunStaticConstructors(ee);<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D16188" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16188</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>