[LLVMdev] Dynamic updates of current executed code

[Misha Brukman]

On Tue, Apr 20, 2004 at 10:52:21AM +0200, Anders Alexandersson wrote:
> Is there an llvm version of the getPointerToGlobal() function as
> outlined, and can the %myNewFunction pointer be used as described? 

Yes, see llvm/lib/ExecutionEngine/ExecutionEngine.cpp . It will compile
the given Function* to machine code, and return a pointer to you. In
your LLVM code, you will have to first cast your function pointer before
storing it, but it should work as you have it.

One thing is that you need to have a pointer to the currently-running
instance of ExecutionEngine to call methods on it... a easy quick hack
would be to create a static variable that the ExecutionEngine
constructor writes its own pointer (this) into, and have a C function
(in ExecutionEngine.cpp) that returns that pointer. Your code can then
access the currently-running ExecutionEngine through that pointer. There
should be a cleaner solution to this...

> Also, does the getPointerToGlobal() take human readable code (.ll) or
> only binary byte code (.bc)? 

ExecutionEngine::getPointerToGlobal() takes a Function*, which means
it's a memory representation of an LLVM function. This implies it has
been already parsed from text or inputted from a binary file.

> Is there a specification of how to write binary byte code directly, so
> we do not have to externally call the llvm-as utility?

You probably don't want to construct directly by hand. ;)
In case you wish to know WHY you don't want to do that, see
llvm/lib/Bytecode/{Writer,Reader}/*

Here's an idea:

In tools/llvm-as/llvm-as.cpp, you can see how the assembly parser really
does its job: it calls ParseAssemblyFile(InputFilename) which returns it
a Module*. 

ParseAssemblyFile is defined in llvm/lib/AsmParser/Parser.cpp; something
similar to it, but one that accepts a string instead of a filename could
be implemented.

However, there is a catch (as I see it, Chris may correct me):

The entry to the parser is to parse a whole Module.  The new function
that you write may reference other functions. When you parse a Module,
it has to be complete, so functions that are not defined in the module
are "external". Having a definition for those functions will make those
external functions different (in terms of their location in memory) and
hence different value for Function*, which will mess with the
ExecutionEngine as it uses a map Function* => memory address of
translation. Other problems would be with types, same idea.

(Is this making sense?)

A solution would be perhaps to use a different entry point into a parser
that would just parse a Function instead of a whole Module. It should
then resolve the types it finds to the already-parsed Module in memory.
I don't think this has been done yet.

-- 
Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu