[LLVMdev] me being stupid: me vs the llvm codebase...

BGB
Wed, 24 Oct 2007 00:43:28 -0000

oh, ok.

actually, I had partly considered this approach at one point, but opted with the
form I did instead (in large part because it does not involve such a tweak, or
dependency on the previous location).

of course, as noted, due to the possibility of function pointers, this is a
little risky. I had not considered this issue previously, but it is definitely
worth consideration...

I guess the issue then is how likely and how often a function will be
replaced...


it does lead to a possible idea though:
use of an inter-module jump table.

in this way, the actual usage of any external functions involves jumping through
such a table (either directly, or by by making use of an implicit jump).
sad issue though: this could incure a possibly noticable performance overhead
(for normal calls, but it could make moving functions really cheap).


a more selective way of doing this would be helpful (for example, a special
compiler-specific keyword, or some other approach for telling the VM/linker that
a particular function is movable).

this would probably one-off the function, by forcibly relinking it as a proxy to
the function (any future attempts at relinking the function then simply adjust
its associated pointer).

potentially, this could also be made the default behavior for when relinking
functions (if they are being forcibly relinked, well, assume they are being made
movable).

or such...


ccMakeMovable(char *func);    //an explicit call to the VM

__movable void foo(int x)
{
    //do something...
}


even more interestingly:
if the same compiler were also used for static compilation, it could be used as
a special feature to make such dynamic movability available even for statically
compiled and linked code (as is, in my case, parts of the app which are
statically compiled and linked, can't currently be relinked...).

(even more cool: it does not necessarily imply a runtime dependency, since the
stub and proxy variable would be merely passive elements, it could still be
possible to compile and link the code apart from the VM, nevermind that any such
proxy stubs would be useless though...).

absent special compiler support, this could be implemented more manually with an
existing compiler, such as gcc.

example convention:
int Afsd875gSd57g8Th(int x)    //invisible autogen name
{
    //do something
}

int (*__proxy_foo)(int x)=&Afsd875gSd57g8Th;
int foo(int x) { return(__proxy_foo); }

or (assembler):
section .data
__proxy_foo dd Afsd875gSd57g8Th

section .text
Afsd875gSd57g8Th:
push ebp
mov ebp, esp
..
pop ebp
ret

foo:
jmp [__proxy_foo]


or such...


  ----- Original Message -----
  From: Gordon Henriksen
  To: LLVM Developers Mailing List
  Sent: Wednesday, October 24, 2007 9:26 AM
  Subject: Re: [LLVMdev] me being stupid: me vs the llvm codebase...


  On Oct 23, 2007, at 18:19, BGB wrote:


    On Oct 23, 2007, at 11:45, Gordon Henriksen wrote:



      Generally speaking, LLVM neither helps nor hinders here. Maybe someone
will follow up with whether the JIT uses stub functions which would enable
dynamic relinking If not, it would be a straightforward, if platform-specific,
feature to add.




    I don't use proxy or stub functions, I relink them...



  I misspoke. See here:


  http://llvm.org/doxygen/classllvm_1_1JIT.html#a7


  Relinking the function as you describe is risky in the case that the address
of the function has been taken. LLVM's present approach is general.


  — Gordon





------------------------------------------------------------------------------


  _______________________________________________
  LLVM Developers mailing list
  LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
  http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20071024/0cd9f787/attachment.html>