[LLVMdev] Python bindings available.

[Gordon Henriksen]

On May 10, 2008, at 05:44, Mahadevan R wrote:

> I'd like to announce the availability of Python bindings for LLVM.
>
> It is built over llvm-c, and currently exposes enough APIs to build  
> an in-memory IR (and dump it!). It needs LLVM 2.3 latest and Python  
> 2.5 (2.4 should be sufficient, but I haven't tested). Tested only on  
> Linux/i386.
>
> Would love to hear your comments.
>
> [Needless to say, it's all work in progress, but mostly it works as  
> expected. More tests, documentation and APIs will follow.]


Hi Mahadevan,

One more thing I noticed that may be a problem. Automatic finalizers  
like this one are very dangerous when cooperating with the C++ object  
model:

void dtor_LLVMModuleRef(void *p)
{
     LLVMModuleRef m = (LLVMModuleRef)p;
     LLVMDisposeModule(m);
}

Consider the case where a function creates and populates a Module,  
stuffs it in an ExistingModuleProvider for the JIT, then returns the  
ModuleProvider, dropping direct reference to the Module.  
(ModuleProvider takes ownership of the Module.) I presume that your  
Python object is under the impression it owns the Module; when that  
goes out of scope, its refcount goes to zero and it invokes its dtor,  
disposing of the Module. D'oh— now the ModuleProvider has a dangling  
pointer. :) The routine LLVMModuleRef LLVMGetGlobalParent(LLVMValueRef  
Global); poses a related problem; in this case, the returned reference  
is non-owning, so you must not dtor it from Python.

The fix, of course, is providing a dispose routine and requiring the  
user to call it, since you can't know what they've done with the  
pointer. Luckily, the IR is not subject to these subtleties. None of  
your LLVMValueRef wrappers need destructors, either manual or  
automatic, because LLVMDisposeModule will destroy the contained  
objects recursively.

Builders and type handles are unlikely to ever be subject to these  
sorts of circumstances, though, so letting Python garbage collect them  
is advisable.

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080511/20d89e3a/attachment.html>