[LLVMdev] reading a module from a memory string (BitCode)

[Reid Spencer]

Hi Basile,

On Sat, 2007-05-12 at 23:45 +0200, Basile STARYNKEVITCH wrote:
> Hello,
> 
> with the latest LLVM (almost 2.0 CVS) what is the right way to read a module
> from a byte array fetched from a database?

Add your own blocks

> I thought that I could subclass llbm::module to add my own fields
> (typically, a MySQL id number) and then parse it as bitcode, but I am stuck,
> since apparently the only way to parse bitcode is to use a BitcodeReader
> then calling materializeModule gives a fresh llvm Module (not my subclass)

LLVM only knows how to read LLVM stuff. If you want to "add" stuff, you
need to do it in a separate block. The bitstream format is flexible
enough to support reading a new file format that is LLVM+your_stuff. 
> 
> As a general question, are Llvm classes supposed to be usually subclassed to
> add application data (like my modtime and id), or not...

No, not generally. 

What is it that you're trying to do? Sounds like maybe you're trying to
do "front end" type things. The HLVM front end libraries will assist
with many of these kinds of things (associating source line, language
identifier, managled identifier, etc. with corresponding LLVM nodes).
The general approach is to keep references back to the LLVM objects from
another block. None of this exists yet in HLVM, but it will this summer.

> 
> Does any one have some example of reading Bitcode encoded modules? 

Bitcode is only a few weeks old, so I doubt it :)

> Can I assume that such modules are not tied to a particular (LLVM target)
> architecture, in other words can I store into my database modules build on
> AMD64 and reload them on x86 (32 bits)?

Depends on whether you mean "bitcode file format" or "LLVM module". A
module can definitely be tied to a specific target. It completely
depends on what the front end language compiler generates. From a
bitcode file format perspective, the files should be portable as they
are treated as a stream of bits without concern for endianness, etc. 

Your example will work from a file format perspective (you'll get the
same bits out as you got in and they'll have the same interpretation on
the x86 as on the AMD64). But, that doesn't mean it will execute
correctly. If the module has no inline assembly or any other target
specific features (like differences in alignment) then it could work.
Your front end will determine how well this works. If the front end is
llvm-gcc then the answer is "won't work, in general, but might work on
specific test cases".

Reid.
> 
> Regards.