[llvm-dev] llvmcpy: yet another Python binding for LLVM

[Alessandro Di Federico via llvm-dev]

On Thu, 12 Jan 2017 17:30:09 -0800
Philip Reames <listmail at philipreames.com> wrote:

> You mention in your readme that you had to slightly modify the LLVM C 
> headers to get this approach to work.  Can you point out a couple of 
> example changes?  Maybe these are things we should consider taking
> upstream.

Take a look at the `clean_include_file` function:

https://github.com/revng/llvmcpy/blob/master/llvmcpy/llvm.py#L342

Basically CFFI doesn't handle enum entries whose valus is computed
through an expression. In the LLVM-C API sometimes we have 1 << 8.
Also, static inline functions are not handled too (CFFI only handles
function prototypes), so I've to strip them away.

I'm not sure it'll ever be possible to handle unmodified LLVM-C API
headers with no modifications, and given that one explicit aim is to
support older versions of LLVM I'd have to keep that code anyway.

It would be nice, however if that code doesn't have to grow in the
future (e.g., having sophisticated expression as enum values).

A thing I like about the C API is the consistency in function naming
like having LLVMGetSomething/LLVMSetSomething pairs,
LLVMCountSomethings/LLVMCountSomethings pairs and
LLVMGetFirstSomething/LLVMGetNextSomething pairs.

What I'd need would be the ability to know the name of the arguments,
which CFFI doesn't provide. That would allow me to set up slightly more
robust heuristics. For instance I'm now transforming a pair of pointer
arguments followed by an integer as a pointer to an array plus its
size, and it's fine in current versions of LLVM but it's not very
robust. Same argument for error messages, having the argument name
would help. But this is more a CFFI issue.

> I've not familiar with the details of CFFI.  Are the bindings it 
> generates for a particular set of headers specific to the machine
> it's generated on?  Or could the resulting bindings be published and
> reused directly?  If so, hosting a set of bindings for previous
> releases would be a useful service.

I'm not entirely sure they're portable across OS/architectures. What
would be the use case? It takes a moment to generate the bindings but
it's something the module will lazily do for you only once.

--
Alessandro Di Federico
PhD student at Politecnico di Milano