reading, printing, compiling, JIT-ing LLVM modules?

Dear All (and happy new 2007 year)

As a toy hobby project of mine (unrelated to my work [on GCC]), -I'm
dreaming of building an open-source Web CGI application capable of
generating other CGIs- I would like to

(portably) store an LLVM module in bytecode format inside a MySQL
table row (probably inside a BLOB = mysql binary large object = big
array of bytes). AFAIK, this could easiy be done with the
llvm::Module::print function (into a memory ostream) -ie the print
method of the Module class

(portably) read (again, in the same format as above) an LLVM module in
bytecode format from a MySQL table row (probably from a BLOB also)
according to my understanding, the lvm::ParseBytecodeBuffer function
does that. Is it really the inverse of the print method od Module?

JIT-compile in memory this module (on Debian/x86 32bits & Debian/AMD64
64bits systems). I believe the JIT class and its
JIT::getPointerToFunction (and others) method is ok for this.

compile to a C external file, without using any external process for
this C file generation. I believe the lvm::CTargetMachine class does
this, but I am not sure to understand all the details.

possibly, compile to an ELF shared object library, without using any
external process (not even an assembler or linker) for this. I am not
sure it is doable with LLVM 1.9 (I cannot depend upon any external

What is important for this pet hobby project is that the application
should be mostly statically linked (linking dynamically only the,, and nothing else; all the rest
-including LLVM livbraries should be statically linked inside),
working on Debian/x86 & Debian/AMD64 without depending upon any
external program like /usr/bin/gas or /usr/bin/gcc or /usr/bin/ld
(because, being a CGI program, my application does not have access to

Any clues?

And don't hold your breath. This is a pet project I probably won't
have time to complete soon!


LLVM can do everything that you want: store code, jit compile it, etc. What it can't do is provide portability for C code. C is not a portable language: target-specific details like the size of datatypes leak into the generated code, preprocessor symbols are defined differently for different targets, etc.

If you use a portable input language, LLVM can preserve that portability. However, for C, you can't be guaranteed that your input will be portable.