[PATCH] D16188: LLVMRunStaticConstructors can be called before object is finalized, #24028

[Lang Hames via llvm-commits]

Hi David,

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) ?

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.

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.

Cheers,
Lang.


On Thu, Jan 14, 2016 at 3:44 PM, David Herberth via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> Dav1d added a comment.
>
> In http://reviews.llvm.org/D16188#327370, @joker.eph wrote:
>
> > It is not clear to me why LLVMGetPointerToGlobal calls it but not
> LLVMGetGlobalValueAddress (or LLVMAddGlobalMapping or ...)
>
>
> As I mentioned in the Issue (https://llvm.org/bugs/show_bug.cgi?id=24028),
> 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).
>
> 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).
>
> 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.
>
> PS: My current workaround:
> I have an empty function in my module, so before calling the constructors
> I run the function:
>
>                 // workaround which calls ee->finalizeObjects, which makes
>                 // LLVMRunStaticConstructors not segfault
>                 LLVMDisposeGenericValue(LLVMRunFunction(ee, "vmain", []));
>                 LLVMRunStaticConstructors(ee);
>
>
> http://reviews.llvm.org/D16188
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160115/f30a4a57/attachment.html>