[LLVMdev] Redefining function

Jeffrey Yasskin jyasskin at google.com
Sun Jan 31 08:46:28 PST 2010


On Sun, Jan 31, 2010 at 6:44 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Jeffrey,
>
>>  2. It could compile C, and either replace B's machine code with a
>> jump to C, or replace all calls to B with calls to C. Aside from not
>> having the infrastructure to do this, it's not thread-safe:
>> http://llvm.org/PR5184.
>
> if all calls were via a handle (i.e. load the function pointer out of
> some memory location then jump to it), then you could compile C,
> atomically replace the pointer-to-B with the pointer-to-C in the memory
> location, and later free B using some kind of user-space read-copy-update
> type logic.  This could be managed transparently by the JIT (i.e. in the
> IR you would have direct calls, that are implemented by a jump to a place
> that loads the function pointer then calls it).  If you don't want to use
> handles, then there are also various possibilities for thread-safe code
> patching (eg: the linux kernel does this kind of thing in various places),
> but this is of course more complicated.  That said, if the IR optimizers
> have inlined your original function everywhere, then replacing the function
> later won't have any effect...

Yep. I think the JIT should provide thread-safe code patching as a
service. The bug describes how to do it on x86 chips, but not PPC or
ARM. Because it requires the call sites to be aligned in particular
ways, or, on unsupported processors, to become indirect calls, I think
we'll want to attach an attribute to the call/invoke instruction
marking it as patchable. I'm definitely not going to get time to do
this before 2.7 though.




More information about the llvm-dev mailing list