[LLVMdev] Primer with LLVM

[Reid Spencer]

On Fri, 2004-12-31 at 05:30, Francisco Puentes wrote:
> Hi again, and thanks (Reid) for your fast response:

Glad to help.

> 
> Yes, it works!!! Only changing the order of libraries in the Makefile.

Great!

> 
> Nowaday I have my software with the capability of compile assembly, bytecode
> (from buffer and file) and link them with a set of libraries. It seems to
> work perfectly (I don't generate code yet).

Cool. Next step: generate code! :)

> My real aim is to have a process (host) with execute several no-jit binaries
> (guest) each one in his own thread (not forked!! each one with a main
> function). Guest and host have interdependencies in both ways. This is a
> part of my doctoral degree.
> 
> Before now, I was using TCC (Tiny C Compiler), but it have a big lack: it
> isn't reentrant. It can only have one generated program at time. For this
> reason I agree to use LLVM (two days ago) and rebuild all the project. 8-|

Careful here. Much of LLVM is not re-entrant (yet!) either. However, if
you're written your own execution engine and made it synchronize wisely,
you should be okay. Making LLVM re-entrant is on the "to do" list, we
just haven't had the time/manpower yet. If you find things in LLVM that
would help make it more re-entrant, we'd gladly accept patches for it.

> LLVM Makefile system is great!! 

:)

> But I have no time to change nowadays all my
> current Makefiles. Maybe later.

Okay, sounds reasonable.

> I have noticed that LLVM have memory leaks; exactly a poor main with a simple
> "return 0;" linked with the LLVM libraries report memory laks using
> valgrind. Is it normal?

Yes, unfortunately it is. LLVM uses quite a few static variables because
they are needed throughout the program's life span. They are constructed
at static initialization time and never modified or freed so they show
up as "leaks" in valgrind. Generally this isn't a problem. I would like
to see this cleared up eventually too; its one of the stumbling blocks
of making LLVM re-entrant as well. However, several important features
of the LLVM Core (like the type system) depend on global variables. For
example, a Type* for any given type is allocated exactly once so that
types can be compared by pointer equality. To make that magic happen, we
need to keep track of types globally and a static variable is currently
used for that. 

> 
> Now I have other problem: I have a Module and I need generate a iostream
> (memory) with native x86 code (maybe elf/coff) to be executed later (into
> the guest process space, without fork!!). I studied llc and lli, but they
> don't help me much. Any idea? Are there any guy working in some like that?

There's two approaches that could be used here:

1. lli-style. Save the Module as bytecode and dynamically compile it at 
    runtime. Your thread would: read the bytecode, convert it to x86
    code in memory and then execute it directly from memory.

2. llc-style. Use llc to convert the module to assembly code, then use
    GCC (or as and ld with a little more effort) to create a dynamically
    loadable shared object (.so or .dll). You can then instantiate a
    DynamicLibrary object to load your compiled library into your 
    thread (include/llvm/System/DynamicLibrary.h). Once loaded, your
    thread can use DynamicLibrary::GetAddressOfSymbol to find "main" and
    start executing it.

> A sample code will be greatfully :-)

Unfortunately, I don't know of any code that does this. bugpoint is
close, but it uses fork(2). 

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041231/f72fe936/attachment.sig>