Really JIT isn't my goal. I prefer use a native execution engine; and ok, I
don't need save the generated Module so it ever lives in memory, so if LLVM
doesn't generate relocatable code it's fine for me.
About the reentrant lacks of LLVM, I can convert my own code - which build
the Module - into a critical section so I think it is enough; but I need to
know if several independent Modules can live in the same address space
running at same time (I agree).
Would be great if we append into the documentation several "patters"
to show
how perform with LLVM. It would accelerate the learn curve for beginners
like me, avoiding basic errors and mistakes. If I reach a good level with
LLVM I can make these.
Have you a sample to generate code into memory?
To move LLVM into a reentrant library we could move all global symbols into
a structure which would be the LLVM context. All (ok, not all) constructor
classes would have as first parameter this context, so it would be easy
lock/unlock the context and allow critical sections in the code.
Happy new year :-)
===========================================You can use some of this accounts:
* fran at cic-online.net
* fpuentes at udc.es
fpuentes at acm.org
fpuentes at edu.xunta.es
fpuentes at hotmail.com
===========================================
-----Mensaje original-----
De: Misha Brukman [mailto:brukman at uiuc.edu]
Enviado el: viernes, 31 de diciembre de 2004 19:20
Para: Francisco Puentes
CC: 'LLVM Developers Mailing List'
Asunto: Re: [LLVMdev] Primer with LLVM
On Fri, Dec 31, 2004 at 02:30:00PM +0100, Francisco Puentes
wrote:> 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?
In addition to what Reid said, I would like to point out that
llvm/tools/lli/lli.cpp is not the entire JIT compiler, a lot of it lives
in llvm/lib/ExecutionEngine/* and llvm/lib/ExecutionEngine/JIT/* .
Together, they provide a lot of the machinery that you're looking for.
The other point is that the JIT, when it writes out code to memory, is
no longer relocatable, i.e. it's bound to the addresses where it's
written, with all symbol references resolved. LLVM does support
relocations, but if you need to save binary code and then load it in
different address spaces, or write out elf/coff binaries directly, you
will need to do some work such as creating a BinaryObjectCodeEmitter (to
parallel the current MachineCodeEmitter) and properly write out the
correct binary image, with relocations intact.
--
Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu