[LLVMdev] LLVMdev Digest, Vol 82, Issue 7

[Owen Anderson]

On Apr 4, 2011, at 11:17 AM, Xin Tong Utoronto wrote:

> sounds like a good idea to me. but one of the current issues of back-patching in the LLVM is that the back-patching is not done atomically on some of the architectures, i.e. Intel x86. and this makes LLVM JIT not thread-safe in lazy compilation mode. what we need to make sure is that the  "updating the resolution for a given symbol" you mentioned is done in an atomic fashion.

That's certainly a tricky issue, but I'm not sure it impacts the high-level design.  It just requires rt-dyld to be sufficiently smart for a given target, or for the client to enforce mutual exclusion

> also, how much more overhead is the  "updating the resolution for a given symbol, and asking rt-dyld to re-link the executable code" in comparison to simple overwriting an instruction ?

Obviously relinking every relocation in a large program in order to perform a single back patch is unacceptable, but that just means we'd need to give rt-dyld an entry point for "relink only this one symbol."  At that point it's essentially the same amount of work.  Indeed, my whole point is that the process of back patching is just a special case of incremental, dynamic relinking!

--Owen